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ABSTRACT 


The  Electronic  Waifere  Integrated  Reprogramming  Database  (EWIRDB)  is  the 
primary  Department  of  Defense  (DoD)  approved  source  of  electronic  warfere  (EW)  data. 
Its  utilization  in  the  areas  of  battle  planning  and  EW  research  enables  our  military  forces  to 
effectively  exploit  the  electromagnetic  q)ectrum  and  shape  the  outcome  of  battle.  The 
EWIRDB,  however,  lacks  a  viable  conceptual  data  model.  EWIRDB  data  are  represented 
in  digoint  parametric  tree  models  that  are  mplementation-oriented;  to  the  extent  that  the 
tree  structures  are  used  as  conceptual  modeling  tools,  their  hierarchical  form  is  too 
restrictive  to  adequately  describe  EW  data  semantics.  Moreover,  these  structures  address 
only  technical  parametric  data.  Associated  administrative,  reference,  and  comment  data 
are  excluded.  In  practice,  the  EWIRDB  is  described  in  terms  of  the  coded  and  record- 
based  format  of  its  output  media,  not  its  conceptual  model 

The  primary  goal  of  this  thesis  is  the  development  of  a  semantically-in:q)roved 
conceptual  design  of  EWIRDB  data  based  on  the  object-oriented  data  model  (OODM). 
The  secondary  goal  of  the  thesis  is  the  specification  of  a  logical  design,  based  on  the  new 
conceptual  design,  to  provide  the  structure  for  a  subsequent  irxplementation  of  EWIRDB 
data  on  the  Multimodel  and  Multilingual  Database  System  (M^DBS)  in  the  Laboratory  for 
Database  Systems  Research  at  the  Naval  Postgraduate  School 

The  results  of  the  work  contained  herein  are:  (1)  an  object-oriented  conceptual 
design  of  EWIRDB  data  that  supports  the  semantics  of  both  the  file  format  and  tree 
structures,  and  (2)  the  specification  of  an  object-oriented  logical  design  for  an  M^DBS 
ircplementation  of  sarrqple  EWIRDB  data. 
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I.  INTRODUCTION 


Iq  this  thesis,  I  propose  an  object-oriented  design  for  a  rqpresaitative  portion  of 
the  Electronic  Warfere  Integrated  Reprogramming  Database  (EWIRDB).  In  this  chapter, 
I  highlight  the  inq)ortant  role  of  the  EWIRDB  in  the  national  defense  and  provide  a 
description  of  the  current  format  of  the  database.  I  conclude  with  ^ecific  thesis 
objectives  and  an  outline  for  the  organization  of  the  theas. 

A.  AN  OVERVIEW  OF  THE  EWIRDB 

Advances  in  electronic  warfare  (EW)  technology  have  had  tremendous  iiiq)act  on 
modem  military  operations.  The  application  of  electromagnetic  energy  to  secmre  friendly 
use  of  the  electromagnetic  spectrum,  and  to  detect,  reduce,  or  prevent  its  hostile  use  may 
well  be  the  decisive  factor  in  the  outcome  of  battle.  A  force  that  effectively  utilizes  the 
electromagnetic  spectrum  gains  the  initiative.  A  force  that  exploits  the  weaknesses  in  an 
adversary’s  EW  systems  renders  the  adversary  blind  to  the  actual  tactical  situation. 
Success  in  EW  is  a  prelude  to  victory.  Failure  in  EW  is  militarily  devastating. 

In  the  context  of  today’s  electronically-dependent  warfare,  frequent  data  collection 
and  analysis  is  essential  to  the  development  of  EW  technologies  to  counter  the  enemy 
threat.  Efi&cient  maintenance  of  the  latest  data,  obtained  directly  from  measurement,  or 
indirectly  via  electronic  intelligence  (ELINT),  is  the  basis  of  successful  EW.  The  National 
Air  fritelligence  Center  (NAIC)  maintains  the  latest  data,  in-depth  and  specific,  on  EW 
systems  of  the  United  States,  friendly  forces,  and  non-friendly  forces.  These  data  are 
stored  in  the  Electronic  War&re  Integrated  Reprogranmnng  Database  (EWIRDB). 

“The  EWIRDB  is  the  primary  Department  of  Defense  (DoD)  approved  source  for 
technical  parametric  and  performance  data  on  noncommunications  emitters  and  associated 
systems. ”[1]  Noncommunications  emitters  include  radars,  jammers,  navigational  aids, 
transponders,  target-sensing  systems,  and  others.  AH  such  emitters  generate  and  receive 
electromagnetic  radiation  and  may  be  used  to  gain  the  advantage  in  armed  conflict. 
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EWIRDB  emitter  data  are  therefore  indispensable  in  the  analysis  and  execution  of  EW; 
without  them,  our  ability  to  effectively  manipulate  the  electromagnetic  spectrum  would  be 
coit5)romised. 

The  EWIRDB  is  the  union  of  data  from  three  constituent  sources.  The  National 
Security  Agency  (NSA)  contributes  data  from  its  “BCilting”  database.  Obtained  throng 
ELINT,  Kilting  data  are  referred  to  as  observed  data  in  the  EWIRDB.  Observed  data 
result  from  the  direct  measurement  and  analysis  of  an  emitter’s  electromagnetic  signature 
following  the  signal  intercept;  they  are  fundamental  in  describing  an  emitter’s 
performance.  The  Scientific  and  Technical  Intelligence  (S&TI)  community,  under  the 
jurisdiction  of  the  Defense  Intelligence  Agency  (DIA),  contributes  parametric  data 
assessments  to  the  EWIRDB.  S&TI  systems  analysts  consider  aU  available  sources  of 
information  and  then  estimate  or  derive  the  total  operational  capability  of  an  emitter. 
Derived  parametric  data  in  the  EWIRDB  are  referred  to  as  assessed  data.  The  United 
States  Noncommimications  Systems  Database  (USNCSDB),  supported  by  the  Air  Force 
Information  Warfare  Center  (AFIWC),  holds  data  on  US  owned  and  operated 
noncommunications  emitters.  USNCSDB  service  analysts  provide  inputs  based  on 
evaluation  of  system  specifications.  EWIRDB  data  of  this  type  take  the  same  format  as 
assessed  data,  and  for  this  reason,  are  generally  referred  to  as  assessed  data  as  weU. 

The  EWIRDB  is  thus  a  data  composite.  Moreover,  this  pooling  of  EW  data  may 
reflect  different  data  values  from  different  sources.  Figure  1  depicts  the  EWIRDB  as  a 
composite  of  its  three  contributory  sources. 

Developed  in  the  seventies  to  support  the  reprogramming  of  EW  systems,  the 
EWIRDB  and  its  role  has  since  grown  in  both  scope  and  in  significance.  While  its  primary 
focus  remains  in  EW  software  reprogramming,  the  EWIRDB  has  become  vital  in  other 
areas:  EW  research,  development,  test,  and  evaluation  (RTD&E);  modeling  and 
simulation  (M&S);  training  and  acquisition.  Merits  of  the  EWIRDB  are  revealed  by  post- 
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Desert-Storm  figures:  the  value  of  the  reprogrammable  EW  equipment  directly  supported 
by  the  EWIRDB  has  been  estimated  at  $30  billion;  the  value  of  the  operational  systems, 
RTD&E,  M&S,  and  training  and  acquisition  programs  that  employ  the  EWIRDB  has  been 
estimated  to  be  $1  trillion  [1], 

In  short,  the  EWIRDB  is  an  indispeusable  tool  that  helps  to  bridge  the  gap 
between  data  analysis  and  effective  exploitation  of  the  electromagnetic  environment  by 
EW  systems.  It  is  a  medium  whose  use  ultimately  helps  maintain  mflitary  readiness  and 
minimize  the  loss  of  life  in  combat. 

B.  THE  FORMAT  OF  THE  EWIRDB 

Altbmigb  effective  in  its  ircplementation,  the  data  model  of  the  EWIRDB  is 
problematic.  The  EWIRDB  is  described  in  terms  of  a  data-in:q)lementation  model  to  the 
exclusion  of  a  legitimate  semantic  data  model  Data  is  presented  in  a  hierarchical  tree  that 
is  inherently  arbitrary  and  reliant  on  the  use  of  reference  codes  to  link  related  pieces  of 
data  throughout  the  hierarchy.  The  non-intuitive  hierarchical  organization  and  coding 
scheme  prevent  the  user  from  gaining  a  meaningful  view  of  an  emitter’s  performance 
parameters.  Consequently,  the  nature  and  semantics  of  the  EW  data  are  obscured  by  its 
ciuToit  representation. 

The  administrative  information  maintained  for  emitter  systems  and  their  associated 
parametric  data  entries  is  excluded  from  the  existing  data  model.  The  administrative  data 
are  addressed  only  in  terms  of  the  fi>rmatting  of  the  data  output  file.  This  is  a  major 
shortcoming;  the  administrative  data  are  inoportant  to  the  analysis  and  tracking  of 
parametric  data,  and  represents  a  significant  portion  of  the  database. 

In  general,  the  “intuitiveness”  of  data  representations  and  the  ease  with  wliich  data 
formats  may  be  interpreted  largely  determine  the  usefulness  of  a  database.  The  current 
EWIRDB  oversteps  the  boundaries  of  both  criteria.  So  while  it  remains  the  foremost 
source  of  mission-critical  EW  data,  lack  of  an  adequate  semantic  data  model  ultimately 
results  in  a  reduction  of  the  EWTRDB’s  effectiveness  as  an  instrument  of  EW. 
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1.  The  Parametric  Tree  Model 

The  upper-level  hierarchical  data  model  of  the  EWIRDB  is  illustrated  in  Figures  2 
and  3.  The  Pulsed/Continuous  Wave  (P/CW)  tree  in  Figure  2  is  used  principally  to 
evaluate  and  identify  the  electromagnetic  energy  radiated  by  emitters.  The  Receiver 
Parametric  Performance  (RPA)  tree  in  Figure  3  contains  receiver  design  and  performance 
information  on  the  receiver  portion  of  emitter  systems  and  serves  as  a  vital  reference  in  the 
development  of  electronic  countermeasures  (ECM)  techniques  and  systems.  The  P/CW 
and  RPA  trees  together  provide  a  comprehensive  report  on  an  emitter’s  performance  .  A 
third  hierarchical  structure,  the  Electronic  Countermeasures  (ECM)  tree,  exists;  it  is  not 
shown  in  any  figure.  ECM  tree  data  describe  jamming  systems,  and  are  referenced  in  the 
development  of  electronic  counter-countermeasures  (ECCM)  to  overcome  the  jammer 
threat.  At  present,  however,  the  viability  of  the  ECM  tree  is  being  reevaluated  by  the 
agencies  that  partic^ate  in  and  contribute  to  the  EWIRDB  program  The  ECM  tree  is 
therefore  not  addressed  in  this  thesis. 

a.  The  Parametric  Tree  Structure  and  Notation 

As  depicted  in  Figures  2  and  3,  the  tree  structures  graphically  diow  how 
emitter  data  are  catalogued.  “The  tree  is  a  management  tool  that  orders  a  long  list 
logically  and  hierarchically  in  a  way  that  proceeds  firom  broad  characteristics  through 
levels  of  successively  finer  characteristics”  [1].  Each  branch  contains  a  heading  or  label  to 
indicate  the  type  of  parameters  or  attributes  associated  with  the  branch.  For  exanq)le, 
“SIGNAL  POWER”  of  the  11  B  (B)  SIGNAL  POWER  branch  in  Figure  2  is  a  branch 
name  or  heading.  Branches  contaiu  zero  or  more  parameters.  A  branch  with  zero 
subordinate  parameters  is  referred  to  as  a  “superheader”.  Superheader  branches  pose  a 
unique  modeling  problem  -  they  contain  no  data  and  are  not  reflected  in  the  data  contained 
within  the  database.  However,  superheaders  are  usefiil,  despite  their  lack  of  parametric 
data,  in  identifying  a  major  areas  of  interest  to  be  deconposed  in  subordinate  branches. 
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10  B  (A)  GENERAL  INFORMATION 


11  B  (B)  SIGNAL  POWER 


1  B  P/CWTREE 


:12  B  ANTENNA 


1211  B  (C)  TX  ANTENNA  POLARIZATION 

121  B  ANTENNA  POLARIZATION 

1212  B  (D)  RX  ANTENNA  POLARIZATION 

1213  B  (E)TX/RX  ANTENNA  POLARIZATION 

1221  B  (F)  TRANSMIT  ONLY  ANTENNA 

122  B  ANT  CHARACTERISTICS 

1222  B  (0)  RECEIVE  ONLY  ANTENNA 

1223  B  (H)  antenna  POLARIZATION 

1311  B  (I)  PULSED  SIGNAL  SHAPE  (AM) 


131  B  PULSEDSIGNAL 

1312  B  (J)  PRI/PGRI 

13123  B  (K)  MULTIPLE  PULSE  GROUPS 

13131  B  (L)  RFUNE  STRUCTURE 

13  B  FREQUENCY  AND 

1313  B  FREQUENCY  j 

13132  B  (M)  PULSED  RF 

MODULATION  CHAR 

1321  B  (P)  CW  FREQUENCY 

132  B  CW 

1322  B  (0)  CWMODULATION 

14  B  (R)  ASSOCIATED  SIGNALS/SYSTEMS 


Thus,  in  a  parametric  tree,  branches  categorize  emitter  and  signal 
parameters,  whereas  parameters  hold  actual  data  values  in  the  database.  A  numbering 
system  is  also  provided  for  describing  branching  throughout  the  depth  of  the  parametric 
tree.  The  branch  number  is  given  as  the  first  entry  on  a  branch.  Each  branch  has  a  single 
predecessor  and  is  assigned  a  unique  number  to  define  a  unique  path  from  the  root  of  the 
tree  to  any  given  branch.  The  “1 1”  of  the  11  B  (B)  SIGNAL  POWER  branch  in  Figure  2 
is  an  example  of  a  branch  number. 

As  q)ecified  by  branch  markers  called  subfile  codes,  data  are  organized 
throughout  the  tree  to  effect  logical  groupings  of  parameters.  Subfile  codes  appear  in 
parentheses  in  Figures  2  and  3.  Data  subhierarchies  rooted  at  subfiOle-coded  branches  are 
meant  to  encapsulate  major  aspects  of  an  emitter’s  performance  or  convey  the  semantics 
of  high-level  emitter  and  signal  characteristics:  Subfiles  are  therefore  equivalent  to 
subtrees,  and  accentuate  major  groupings  of  related  data.  The  “(B)”  listed  on  the  11  B 
(B)  SIGNAL  POWER  branch  in  Figure  2  indicates  that  subfile  B,  rooted  at  branch  11, 
contains  data  that  in  the  composite  is  descriptive  of  the  hi^-level  characteristic  “SIGNAL 
POWER”. 

All  branches  and  parameters  in  the  EWIRDB  are  not  apphcable  to  all 
database  users.  A  branch  or  subordinate  parameter  may  be  usefiil  to  an  S&TI  analyst,  for 
instance,  and  meaningless  to  Kilting  analyst.  Likewise,  the  data  in  a  particular  branch  may 
be  apphcable  to  all  users.  Parametric  trees  contain  usage  codes  to  distinguish  usability  of 
branches  and  parameters  among  participating  agencies.  The  non-parenthesized  “B”  on  the 
11  B  (B)  SIGNAL  POWER  branch,  for  example,  indicates  that  the  SIGNAL  POWER 
branch  is  used  for  Kilting,  S&TI,  USNCSDB,  and  NSRL  (National  SIGINT  Requirements 
List)  purposes.  In  other  words,  that  branch  is  apphcable  to  ah  agencies  that  use  the 
EWIRDB.  The  other  codes  are  K  for  Khting  and  NSRL  usage,  E  for  S&TI  assessed  data 
and  USNCSDB,  and  N  for  NSRL-only  usage. 

The  hierarchy  depicted  in  Figure  4  offers  perspective  on  the  complexity  of 
the  parametric  tree.  Specificahy,  ah  branches  subordinate  to  branch  121  B  ANTENNA 
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121X11  B2  LINEAR  POLARIZATION 


1211  B  TX  ANTENNA  POLARIZATION 


121  B  ANTENNA  POLARIZATION 

1212  B  RX  ANTENNA  POLARIZATION 

1213  B  TX/RX  ANTENNA  POLARIZATION 

121X1  B2  FIXED  POLARIZATION 

.10  B  4  TIME  TO  SWITCH  MILLISEC 

.20  B  4  AUTO  OR  MANUAL  SWITCHING  (TEXT) 


i  121X2  B  2  VARIABLE  POLARIZATION 


.1 0  B 1  MAJOR  AXIS  TILT  ANGLE  DEG/HOR 

.20  B  6  AXIAL  RATIO  DB 


121X12  B2  CIRCULAR  OR  ELLIPTICAL 


.10  B  2  SENSE  (LH-RH) 

.20  B  5  AXIAL  RATIO 

.30  B  2  MAJOR  AXIS  TILT  ANGLE  (ELLIPSE) 

(TEXT) 

DB 

121X21  B  2  ADAPTIVE  POLARIZATION 

.01  B  2  CHANGE  PATTERN 

.10  B  2  RATE  OF  CHANGE 

.20  B  2  REASON  FOR  CHANGE 

(TEXT) 

HERTZ 

(TEXT) 

1 21 X22  B  2  MANUAL  POLARIZATION  CHANGE 

.1 0  B  2  RATE  OF  CHANGE 

.20  B  2  REASON  FOR  CHANGE 

HERTZ 

(TEXT) 

121X23  B  2  PERIODIC  PROGRAMMED  POLARIZATION 

.10B3  RATE  OF  CHANGE 

.20  B  4  CHANGE  PATTERN 

HERTZ 

CTEXl) 

121X24  B  3  POLARIZATION  MODULATION 

.10  B  5  CONIlNUOUSmiSCREIEPOLARIZA'nONCrEXr) 


.20  B  4  MODULATTNO  WAVEFORM  OR  CODE  (TEXT) 
.3  0  B  4  MODULATING  RATE  MHZ 

.40  B  4  NBR  OF  DISCRETE  POLARIZATIONS  INTEGER 
.50  B  5  BIT  LENGTH  MICROSEC 

.60  B  5  NBR  OF  BITS  DSTTEGER 


121X3  B  2  CROSS  POLARIZATION  CHAR 
.1 0  B  3  PATTERN  PEAK  OFKCT  DEGREES 
.20  B  5  PATTERN  PEAK  RESPONSE  DB 


Figure  4.  A  Detailed  Portion  of  the  P/CW  Tree 


8 


POLARIZATION  in  the  P/CW  tree,  that  is  all  parameters  associated  with  the  branch,  are 
revealed.  This  portion  of  the  parametric  tree  is  neither  the  most  complex  nor  the  most 
populated,  but  it  is  a  precise  and  representative  sanq)ling  of  the  data  that  reside  in  the 
lower  levels  of  the  parametric  tree. 

The  new  notation  in  Figure  4  requires  a  brief  explanation.  A  parameter  is 
listed  with  a  two  digit  decimal  number  as  a  means  to  differentiate  between  parameters  in  a 
given  branch.  (Branches  themselves  include  the  decimal  notation,  “.00”,  but  the  notation  is 
implicit  and  not  shown  in  the  tree  model.)  The  combination  of  the  branch  number  and  the 
two-digit  decimal  number  is  referred  to  as  the  parametric  number.  Thus,  locating  a 
parameter  within  the  tree  or  within  an  output  data  file  is  a  straightforward  fimction  of 
indexing  into  the  data  via  the  parametric  number.  For  exanq)le,  parametric  number 
121X1.10  indexes  to  the  parameter  .10  B  4  TIME  TO  SWITCH  under  the  121X1  B  2 
FIXED  POLARIZATION  branch  in  Figure  4.  (The  X  in  the  branch  number  is  a  variable 
that  specifies  the  type  of  antenna  being  considered,  i.e.,  transmit,  receive,  or  transmit  and 
receive.  The  variable  takes  on  the  value  1,  2,  or  3,  accordingly.) 

Additionally,  since  each  parameter  contains  data,  each  includes  an  entry  for 
units  of  measure.  Branches,  in  contrast,  are  not  data  entries  but  rather  indicate  that 
parametric  data  groupings  may  be  identified  by  a  branch  name  or  number,  and  therefore 
do  not  specify  units  of  measure. 

b.  The  Limitations  of  Hierarchical  Data  Modeling 

In  general,  the  hierarchical  data  modeling  of  the  EWIRDB  parametric  trees 
is  misleading  in  its  representation  of  parametric  data.  Aside  firom  highli^ting  the 
con5)lexity  of  the  EWIRDB  parametric  tree,  the  sanq)le  hierarchy  in  Figure  4  also  e?q)oses 
the  arbitrary  nature  of  the  trees’  hierarchical  structure.  An  inability  to  precisely  represent 
data  semantics  is  common  to  generic  tree  structures  such  as  those  of  the  EWTERDB.  The 
current  EWIRDB  tree  model  is  strapped  with  this  inherent  arbitrary  quality  that  limits  the 
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EWIRDB’s  eflfectiveiiess  as  a  database  and  places  the  burden  of  data  interpretation  on  the 
user. 

Specifically,  the  parallel  branches,  121X1  B  2  FIXED  POLARIZATION, 
121X2  B  2  VARIABLE  POLARIZATION,  and  121X3  B  2  CROSS 
POLARIZATION  CHAR,  seem  to  indicate  that  for  a  given  antenna,  polarization  is 
either  fixed  or  variable  or  exhibits  cross  polarization  characteristics.  This  is  not  actually 
the  case.  For  a  given  antenna,  polarization  is  either  fixed  or  variable,  and  all  antennas  may 
be  described  by  cross  polarization  characteristics.  Whereas  the  fixed  and  variable 
polarization  branches  determine  a  clear  boundary  based  on  fimdamental  differences  in  an 
antenna’s  characteristics,  the  cross  polarization  branch  is  applicable  to  all  antennas, 
regardless  of  their  differences.  The  hierarchical  structure  in  Figure  4  does  not  convey  this 
idea.  It  provides  only  a  generic  and  inadequate  treatment  of  the  intended  data  semantics. 

A  CTttiilaT  situation  arises  in  the  hierarchy  rooted  at  branch  121X2  B  2 
VARIABLE  POLARIZATION  in  Figure  4.  The  arbitrary  nature  of  the  hierarchical 
modeling  structure  depicts  a  variably  polarized  antenna  that  appears  to  be  rigged  as  one  of 
fi)ur  types:  adaptive,  manually  changed,  periodic  programmed,  or  modulated.  Again,  this 
does  not  accurately  reflect  the  intended  meaning  of  the  data.  The  correct  interpretation  is 
that  a  given  variably  polarized  antenna  can  be  described  as  one  of  three  types:  adaptive, 
manually  changed,  or  periodic  programmed.  And  just  as  the  cross  polarization  branch 
appHed  to  any  given  entry  in  the  preceding  antenna  polarization  branch,  the  polarization 
modulation  branch  describes  characteristics  common  to  all  variably  polarized  antennas. 
The  polarization  modulation  is  therefore  not  a  criteria  by  vriiich  to  categorize  types  of 
variable  polarization. 

Another  flaw  in  the  EWIRDB  tree  model  is  a  collateral  effect  of  the  general 
layout  of  the  data.  Parametric  data  is  scattered  over  a  large  number  of  separate  records 
coinprising  two  distinct  and  largely  independent  structures,  the  P/CW  and  RPA  trees.  A 
search  of  these  two  distinct  structures  and  their  associated  parameters  is  required  to 


10 


ascertain  the  performance  of  a  given  emitter.  Consequently,  the  global  view  of  an 
emitter’s  performance,  from  a  modeling  perspective,  is  obscured. 

Deficiencies  in  the  parametric  tree  model  are  further  exacerbated  by  the 
fact  that  the  trees  are  designed  to  characterize  only  parametric  data.  The  EWIRDB  also 
contains  administrative,  reference,  and  commentary  information,  all  associated  with 
parametric  data.  At  best,  then,  even  if  the  trees  were  perfect  parametric  data  modeling 
tools,  only  a  portion  of  EWIR  data  would  have  been  taken  into  account. 

The  data  not  included  in  the  parametric  tree  are  loosely  modeled  in  terms 
of  a  file  structure.  The  file  structure  is  not,  however,  a  data  model.  It  is  a  descr^tion  of 
the  data  as  presented  in  the  output  form  Parametric  data  is  therefore  also  described  in 
terms  of  the  output  format.  While  the  file  “model”  incorporates  all  aspects  of  the 
database,  the  overall  semantic  picture  is  difficult  to  grasp;  the  file  format  is  also  complex 
and  disjoint. 

2.  The  File  Structure  of  the  Output  Data 

The  EWIRDB  output  file  format  is  designed  to  provide  a  con5)rehensive  view  pf 
parametric  and  associated  data  for  emitters.  It  is  cryptic  in  presentation,  however,  and 
does  not  compensate  for  the  lack  of  a  semantically  correct  data  model  While  the  view  of 
an  emitter’s  parametric  and  associated  data  in  the  output  file  is  complete,  it  is  non- 
intuitive.  The  Technical  ELINT  Reference  File  format  (TERF)  is  the  standard  distribution 
format  for  the  EWIRDB  and  is  composed  of  six  different  types  of  records,  referred  to  as 
logical  information  records.  The  record  types  are  q)ecified  as  follows,  with  the  record 
name  preceding  the  record  type  designator  in  parentheses:  Classification  Record  (SOO), 
Emitter  Name  Record  (SOI),  Subfile  Header  (S02),  Parametric  Data  (SOS), 
Reference  Data  (S04),  and  Comments  (SOS)  [1]. 

A  brief  description  of  the  TERF  data  fields  is  required  to  bridge  the  gap  between 
the  data  as  modeled  in  the  parametric  trees  and  the  data  as  presented  in  the  TERF  output. 
Because  the  EWIRDB  consists  of  data  merged  from  different  sources  (see  Figure  1),  some 
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fields  are  source-specific.  A  tabular  summary  of  the  parametric  data  and  other  types  of 
data  m  the  output  file  is  provided  in  Figure  5.  In  the  figure,  “assessed  data  only”  refers  to 
both  S&n  and  USNCSDB  contributed  data,  as  stated  earlier  in  Section  LA.  A  full 
description  of  the  TERF  format,  including  the  actual  ‘look”  of  an  output  file,  is  given  in 
[1]. 

Three  fields  do  not  appear  in  Figure  5  but  are  common  to  all  records  in  a  file.  The 
first  is  Record  Type,  which  iq)ecifies  the  record  as  SOO,  SOI,  S02,  S03,  S04,  or  SOS.  The 
second  field  is  the  Source  Designator,  v^diich  identifies  the  contributory  source  of  the  data 
contained  in  that  record;  K  for  Kilting,  E  for  S&Tl  assessed  data,  and  U  for  USNCSDB. 
The  third  field  is  Notation,  which  provides  the  ELNOT  (ELINT  Notation)  assigned  to  the 
given  emitter.  The  ELNOT  is  an  administrative  label  that  uniquely  identifies  an  emitter. 

Overall,  the  TERF  format  is  complex.  It  represents  a  merger  of  data  from  different 
sources  with  different  needs  and  provides  for  nonstandard,  source-specific  data  formats. 
The  TERF  contains  many  codes.  Some  codes  differ  in  symbology  but  relate  to  identical 
cnmpnnentSj  and  some  apply  to  only  certain  types  of  data.  Other  codes  distinguish 
between  multq)le  versions  of  the  same  parameter,  and  some  relate  mutually  dependent 
parameter  values.  Mode  combinations  and  the  suffix  table  pose  a  particularly  challenging 
modeling  problem  While  modal  relationships  are  critical  in  the  identification  and 
evaluation  of  emitters,  the  relationidiips  as  coded  in  the  suffix  table  are  difficiilt  to  grasp, 
especially  if  emitter  modes  number  in  the  hundreds  of  thousands.  (Suffix  codes  are  given 
more  detailed  treatment  in  Chapter  LV). 

Many  TERF  fields  exist  solely  to  link  information  in  one  portion  of  the  file  to 
information  in  another  segment  of  the  file.  The  coding  and  linking  picture  grows  more 
nomplev  within  the  following  context.  A  TERF  consists  of  emitter  data  partitioned  into 
subfiles  represented  in  the  S02  records.  Each  contributory  source  (Kilting,  S&TI 
Assessed,  USNCSDB)  may  supply  many  different  subfiles  for  a  given  emitter,  each  may 
supply  muh^le  veraons  of  the  same  subfile,  and  sources  may  overlap  in  the  subfiles  they 
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RECORD  i  RECORD  NAME 

i  arTERFFJEW 


DESCRIPTION 


Classification  I  one  SOO  per  emitter 


overall  classification  of  emitter  file 


Kilting  only,  data  of  data  extraction  from  NSA  database 


Emitter  Name 


Emitter  Name 


S&nCode 


SAE  Code 


Multiple  Source 
Review  Date 


Date  of  Last 
Significant  Chang 
Parametric  Update 
Date 


one  SOI  per  contributory  source  (KJE, 


name  commonlj^  associated  with  the  ELNOT 
assessed  data  only;  4  character  code  that  identifies  the 
aggicy  responsible  for  the  ELNOT 
Kilting  only;  4  diaracter  code  that  idaitifies  the  agency 
responsible  for  the  ELNOT 


assessed  data  only,  date  of  the  last  full  review  of  the 
assessed  data  file  for  a  given  emitter 


Kilting  only,  date  of  last  full  review  of  the  Kilting  data 
file  for  a  given  emitter 

date  of  most  recait  diange  to  any  SOS,  S04,  or  805 
record 


Subfile  Header 

one  S02  per  parametric  data  subfile  per  contributory  j 
source;  multiple  S02  records  likely 

Subfile  Tree 
Number 

subfile-coded  brandi  number 

Subfile  Name 

name  (heading)  of  the  subfile-coded  branch 

Subfile  Code 

1  or  2  character  code  daioting  the  subfile  or  subtree 

Technical  Date 

Kilting  only,  date  of  last  diange  in  any  SOS  record 

Parametric  Data 

one  to  many  S03  records  per  parametric  data  entry 
per  contributory  source;  multiple  S03  records  likely 

Tree  Number 

also  called  parametric  number;  index  into  parametric  tree  i 

Suffix  Code 

1  or  2  character  code  assigned  to  help  describe  emitter 
modes;  helps  differaitiate  between  multiple  entries  for 
the  same  tree  number;  links  related  (dqiaident) 
parameters 

\  Measurement  Name 

corresponds  to  brandi/parameter  name  in  parametric  tree  j 

1  Units 

corresponds  to  units  spedfied  for  parameters  in 
parametric  tree;  for  textual  data,  the  format  may  be 
spedfied  here 

i  Lower/Upper  Value 
or  Text 

actual  parametric  data;  for  numeric  data,  lower/ii^iper 
value  is  filled  in  (with  same  values  if  data  is  single¬ 
valued) 

F^ure  5.  A  Description  of  TERF  Elements  (continued  into  next  page) 


13 


1  RECORD 

RECORD  ?<4ME 
atTBRF  FtELI> 

DESCRIPTION^ 

SOS 

cont’d 

Confidence  Level 

assessed  data  only;  specifies  the  analyst’s  confidence  in 
the  parametric  data 

S&TI  Code 

assessed  data  only;  3  character  code  that  idaitifies  the 
agaicy  responsible  for  the  ELNOT 

Reference  Number 

links  SOS  to  a  reference  (S04);  4  character  code  that 
refers  to  a  line  in  an  S04;  1®*  character  in  code  denotes 
the  data  source,  R=Kilting,  A=S&TI  Assessed, 
F=USNCSDB  (differs  from  SOlcode) 

Comment  Number 

code  that  refers  to  a  line  in  an  SOS;  T*  character  in  code 
denotes  the  data  source;  C=Kilting,  K=S&’n  Assessed, 
N=USNCSDB  (differs  from  SOI  and  Reference  Number 
codes) 

Reserve  Mode 

code  to  indicate  that  the  value  of  the  parametric  data,  or 
mode,  is  a  wartime  reserve  mode  (WARM);  also 
indicates  analyst’s  confidaice  in  this  assessment 

Classification 

assessed  data  only; 

U=nmclassified,C=confidaitial,S=secret,  or  T=top  secret 

Releasability 

assessed  data  only;  2  diaracter  code  designating  the 
countries  to  which  the  data  is  releasable 

Date  of  Last 

1  Update 

date  the  last  significant  change  was  made  to  the  data 

Measurement 

Accuracy 

Kilting  only;  +  or  -  range  if  available,  used  with 

1  numerical  parametric  data 

Measurement 
Accuracy  Units 

Kilting  only;  same  as  the  units  field  unless  the  accuracy 
is  so  fine  it  cannot  be  expressed  the  same  way 

Intelligence  Source 

Kilting  only;  1  diaracter  code,  daiotes  type  of  source 
used  to  derive  parametric  data  (ex.  ELESTT,  non-ELINT) 

Preferential  Rating 

Kilting  only;  one  digit  code  to  signify  the  relative 
importance  of  the  data,  the  importance  of  obtaining  the 
data 

S04 

Reference  Data 

zero  to  many  S04  records  per  source  per  emitter  file; 
required  if  a  reference  was  specified  in  an  S03  record; 
provides  a  trace  back  to  original  source  documents 

Reference  Number 

same  as  those  specified  in  the  SOS  records 

Reference  Line 
Number 

sequential  and  contiguous;  many  lines  of  text  may  be 
required  to  describe  a  referaice  for  a  givai  referaice 
number 

Figure  5  cont’d.  A  Description  of  TERF  Elements  (cont’d  into  next  page) 
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RECORD 

r  RECORD  NAME 
i  TERF  F}EL1> 

DESCRIPTION 

804 

cont’d 

Reference  Text 

•  assessed  data  format:  textual  description  of  the 
parametric  data  referaice  followed  by  a  formatted 
classification/releasability  line  (refers  to  the  S04) 

•  Kilting  format:  referaice  text  or  document 
number  (document  title),  report  date,  producer, 
classification  of  the  r^ort 

S05 

Comments 

zero  to  many  S05  records  per  parametric  data  item 
per  source;  required  if  a  comment  was  specified  in 
an  S03;  suffix  table  stored  in  “comment  zero”; 
general  emitter  comments  stored  in  “comment 
one” 

Comment  Number 

same  as  those  in  SOS  records 

Comment  Line 
Number 

sequential  and  contiguous;  many  lines  of  text  may  be 
required  to  describe  a  commoit  for  a  given  comment 
number 

Comment  Text 

used  to  explain,  describe,  elaborate,  and  qualify 
parametric  data  entries  and  modes 
•  assessed  data  format:  includes  a  formatted 

classification  line  for  every  comment;  at  least  one 
classification  line  is  required  for  eadi  comment 

F^ure  5  cont’d.  A  Description  of  T£RF  Elements 
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supply  to  the  EWIRDB.  Each  subfile  in  turn  may  consist  of  many  different  parametric 
data  entries,  and  there  may  be  many  data  entries  for  the  same  parameter  as  represented  in 
the  SOS  records.  Finally,  where  applicable,  parametric  data  links  to  source-specific 
reference  documentation  and  comments  in  the  S04  and  S05  records,  respectively.  And  for 
a  given  emitter,  each  source  may  require  many  S04  and  805  records.  The  effect  of  the 
data  merge,  codes,  and  links  with  this  framework  is  an  elaborate  and  burdensome 
presentation  of  parametric  and  associated  data. 

3.  Summary 

The  EWIRDB  represents  a  chall^iging  database  modefing  problem  The  problem 
stems  jfrom  several  fectors,  the  foremost  of  vdiich  is  the  inherent  conq)lexity  of  the  data. 
Capturing  the  nature  of  EW  systems  and  rignals  is  difficult. 

Additionally,  the  parametric  trees,  the  semantic  basis  of  the  EWIRDB,  have  been 
designed  and  used  primarily  for  database  management,  not  as  data  modeling  tools.  To  the 
exteut  that  the  trees  have  beeu  used  to  model  parametric  data,  their  hierarchical  and 
intrinsically  arbitrary  structure  has  proven  too  restrictive  to  accurately  capture  the 
semantics  of  the  data.  The  database  user  is  therefore  required  to  logically  determine  the 
tme  nature  of  the  data,  if  the  need  for  mterpretation  is  recognized  at  aU. 

Further,  TERF-formatted  EWIRDB  output  provides  a  comprehensive  view  of 
emitter  data,  but  does  not  fill  the  semantic  gap.  While  it  incorporates  the  structure  of  the 
parametric  tree  model  and  catalogues  associated  reference  and  commentary  data,  it  cannot 
be  construed  as  a  data  model.  Moreover,  the  TERF  format  introduces  extras  into  the 
data,  such  as  reference  codes,  to  link  related  pieces  of  information.  The  use  of  codes 
throughout  the  file  muddles  the  meaning  of  the  data. 

Finally,  without  system-supported  semantics,  the  burden  of  EWIR  data 
interpretation  is  transferred  to  the  user.  This  is  not  an  easy  tadc  for  the  user;  the  EWIRDB 
is  difficult  to  conprehend  because  the  nature  and  relationshps  of  EW  data  are  not 
adequately  modeled  and  are  subject  to  coding.  Because  the  EWIRDB  is  generally 


16 


described  in  terms  of  data  m]{)lementation  and  not  data  semantics,  there  exists  a 
requirement  for  the  development  of  a  more  meaningfiil,  iatuitive,  and  system- supported 
design.  The  recent  advance  in  object-oriented  data  modeling  indicates  that  the  object- 
oriented  alternative  may  prove  useful  in  sin^lifying  and  clarifying  the  data  semantics, 
relationidiips,  and  formats  of  the  EWIRDB. 

C.  THESIS  OBJECTIVES 

The  primary  objective  of  this  thesis  is  to  provide  a  new  object-oriented  design  for  a 
sanq)le  portion  of  the  EWIRDB.  NAIC  has  identified  the  EWIRDB  for  our 
experimentation  in  object-oriented  database  design.  The  object-oriented  data  model  is 
arguably  the  most  semantically  rich  and  flexible  of  all  database  design  tools.  The 
effectiveness  of  the  object-oriented  data  model,  however,  remains  untested  for  any  military 
or  warfere-related  deagn  of  the  scope  of  the  EWIRDB. 

The  secondary  objective  is  to  use  the  object-oriented  data  definition  language  (O- 
ODDL)  as  a  design  tool  for  the  q)ecification  of  the  object-oriented  EWIRDB.  At  present, 
the  O-ODDL  used  in  this  thesis  is  the  product  of  a  larger  thesis  effort  that  produced  an 
object-oriented  inter&ce  to  the  Multimodel  and  Multilingual  Database  System  (M^DBS) 
[7]  at  the  Naval  Postgraduate  School  (NPS).  The  O-ODDL  specification  of  a  new 
EWIRDB  derign  is  therefore  a  continuation  of  the  NPS  research.  It  will  ultimately  provide 
an  on-line  object-oriented  EWIRDB  with  which  to  demonstrate  both  the  utility  of  the  new 
M^DBS  object-oriented  interfece,  and  the  usefulness  of  the  new  object-oriented  EWIRDB 
design. 

D.  THE  ORGANIZATION  OF  THE  THESIS 

In  Chapter  n  of  the  thesis,  I  address  basic  issues  in  the  object-oriented  database 
development,  within  the  context  of  conceptual  design  and  logical  design  processes,  hi 
Chapter  HI,  I  provide  the  design  mechanisms  of  the  object-oriented  data  model.  In 
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Chapter  IV,  I  further  describe  the  tools  of  the  proposed  object-oriented  design  and  present 
the  conceptual  design  of  the  EWIRDB.  In  Chapter  V,  I  briefly  describe  the  logical  design 
structures  native  to  the  M^DBS  and  present  the  logical  design.  In  Chapter  VI,  I 
summarize  my  assessment  of  the  new  object-oriented  EWIRDB. 
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n.  DESIGN  CONCEPTS 


Database  design  is  a  mult^base  process.  Each  phase  addresses  a  different  aspect 
of  the  design  process  and  yields  a  separate  design  result  or  model  The  partitioning  of  the 
design  process  in  this  way  guarantees  the  viability  of  each  design  phase  as  a  distinct  entity. 
Moreover,  it  sinq)lifies  the  entire  process,  because  the  corcplexity  of  the  design  problem  is 
also  partitioned.  Only  certain  aspects  of  the  design  need  be  addressed  in  each  phase,  and 
the  designer  is  e?qposed  to  the  details  of  a  given  level  only.  The  correct  and  thorough 
design  of  one  phase  lends  itself  to  the  development  of  a  subsequent  phase. 

In  this  chapter  I  addresses  those  aspects  of  database  design  that  are  central  to  this 
thesis:  the  conceptual  design  and  the  logical  design.  These  are  the  first  phases  in  the 
overall  design  process  and  are  therefore  elemental  to  the  overall  design.  Together,  the 
conceptual  and  logical  design  phases  take  a  proposed  database  fi:om  abstraction  to 
implementable  form 

The  treatment  here  is  generic;  design  mechanisms  specific  to  object-oriented 
database  design  are  examined  in  Chapter  IQ. 

A.  THE  CONCEPTUAL  DESIGN 

Much  like  an  architect’s  sketch  crystallizes  the  customer’s  architectural  design 
vision,  the  conceptual  design  captures  the  nature  of  data  in  a  way  that  closely  resembles 
the  database  users’  perception  of  data  and  the  usage  of  data. 

The  fundamoatal  goal  of  conceptual  database  design  is  thorou^  understanding  of 
the  database  throu^  development  of  a  conceptual  schema.  A  tool  known  as  the  high- 
level  data  model,  also  referred  to  as  a  semantic  or  conceptual  data  model,  is  used.  A 
hi^-level  data  model  is  intuitive,  flexible,  and  con[q)rehensive  hi  its  description  of  data.  It 
is  the  means  by  v^ch  a  schema  is  developed  to  approximate  the  users’  perception  and 
usage  of  the  proposed  database.  To  this  end,  the  set  of  abstraction  concepts  underlying 
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the  semantic  data  model  are  sufficiently  expressive  of  data,  single  in  nature,  unambiguous, 
minimal  in  number,  and  nonoverlapping  in  meaning  [2]. 

Devised  within  the  framework  of  the  high-level  data  model,  the  conceptual  schema 
thus  characterizes  the  structure  of  data.  The  structure  of  the  data  is  the  sum  and 
substance  of  the  database,  enconq)assing  data  types,  data  relationships,  and  data 
constraints.  Since  the  conceptual  design  should  be  intuitive,  its  design  notation  is  typically 
associated  with  a  diagrammatic  rq)resentation  of  its  modeling  constructs.  A  diagram  is  a 
simple,  precise,  high-level,  and  straightforward  means  of  ejq)ressing  the  nature  of  data. 

An  essential  quality  of  a  conceptual  schema  is  that  it  be  independent  of  a  specific 
database  management  ^stem  (DBMS).  A  DBMS-independent  semantic  data  model  is 
generic  and  free  of  any  limitation  or  peculiarity  inq)osed  by  a  particular  DBMS. 
Consequently,  the  details  of  data  implementation  and  physical  data  storage  are  suppressed 
in  the  conceptual  schema.  Such  detail  is  not  useful  in  the  development  of  a  high-level 
conceptual  design.  Accordingly,  the  conceptual  schema  caimot  be  used  directly  to 
implement  the  database.  This,  however,  is  not  disadvantageous.  Rather,  it  highlights  the 
impmtance  of  the  conceptual  design  and  the  value  of  the  conceptual  schema  as  a  stable 
description  of  the  database.  A  stable  database  description  -  file  conceptual  schema  - 
remains  unaltered  by  any  modification  to  the  underlying  DBMS-dependent  logical  and 
phyacal  designs. 

As  the  initial  phase  in  the  design  effort,  conceptual  design  is  paramount  in  database 
development;  the  entire  process  depends  on  the  creation  of  a  stable  and  correct  conceptual 
schema. 

B.  THE  LOGICAL  DESIGN 

The  architect’s  initial  sketch,  like  the  conceptual  schema,  is  the  foundation  for  all 
subsequent  design  work.  After  capturing  the  essence  of  the  customer’s  desires  in  the 
sketch,  the  architect  then  addresses  the  q)edfics  of  the  design  layout.  Decisions  are  made 
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based  on  the  enviromnent  and  the  available  materials.  The  outcome  is  a  blueprint,  a 
q)ecification  for  the  construction  of  the  design. 

As  the  blueprint  follows  the  sketch,  the  logical  design  in  database  development 
follows  the  conceptual  design.  The  logical  design  likewise  yields  a  “blueprint”  of  the 
conceptual  schema  that  accounts  for  the  type  of  database  system  in  which  the  database 
will  reside. 

The  logical  design  is  equivalent  to  a  mapping  from  conceptual  schema  to  the  data 
model  of  the  selected  DBMS.  The  mapping  is  acconq)lished  by  the  designer  via  the 
DBMS’s  native  data  definition  language  (DDL);  the  output  DDL  statements  are 
equivalent  to  a  DBMS-readable  specification  of  the  conceptual  schema.  The  end  result  of 
logical  desigu  is  thus  a  transformation  of  the  database  as  proposed  in  the  conceptual 
design  to  a  database  in  the  DBMS-con3patible  form  for  eventual  realization  in  the  DBMS. 
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m.  OBJECT-ORIENTED  DESIGN  CONCEPTS 


Conceptual  design  and  logical  design,  as  described  in  Chapter  n,  cast  the 
foundation  of  database  development;  a  high-level  data  model  provides  the  mechanisms 
required  to  formulate  these  designs.  Thus,  both  design  processes  proceed  within  the 
framework  of  the  chosen  data  model.  The  data  model  is  therefore  the  starting  pomt. 

The  definitive  measure  of  a  data  model’s  effectiveness  is  it  abstraction  capability, 
or  the  degree  to  AAdiich  its  design  mechanisms  capture  “real-world”  semantics.  Traditional 
data  models,  including  the  hierarchical  model,  are  limited  A^dth  respect  to  their  abstraction 
capabihties.  The  EWIRDB  hierarchical  model  is  a  prime  exan^le;  and  as  detailed  in 
Chapter  I,  the  model  is  fundamentally  deficient  in  its  representation  of  EWIR  data.  For 
traditional  data  models  in  general,  tire  more  coiiq)lex  the  nature  of  the  data,  the  greater  the 
semantic  mismatch  between  the  real-world  data  and  its  representation. 

Object-oriented  database  design,  a  departure  from  traditional  methods,  seeks  to 
eliminate  the  semantic  mismatch  between  real-world  entities  and  their  database 
representations.  The  object-oriented  data  model  (OODM)  is  the  basis  of  the  design 
effort.  The  OODM  is  more  semantically  rich  than  the  earlier  models.  Object-orientation 
more  closely  parallels  the  way  we  observe  the  real-world.  We  are  surrormded  by  objects: 
conq)uters,  cars,  roads,  buildings,  trees,  people,  animals,  the  atmo^here  -  the  list  of 
objects  is  hifinite.  People  tend  to  reason  about  real-world  “objects”  in  terms  of  their 
characteristics,  both  static  and  dynamic.  A  car,  for  kstance,  might  be  classified  by  its 
make,  model,  and  year,  as  well  as  by  its  performance  in  various  drivdng  conditions.  We 
also  tend  to  apply  different  degrees  of  abstraction  to  the  real-world  entities  that  we 
encounter.  Depending  on  a  person’s  point  of  view,  a  real-world  “object”  may  be  looked 
upon  as  a  single,  indivisible  unit,  or  as  the  conq)osite  of  a  number  of  conq)onent  objects. 
Returning  to  the  car  exanq}le,  the  typical  car  owner  probably  takes  the  view  that  a  car  is 
an  integral  unit  that  provides  a  means  of  tran^ortation.  A  car  mechanic,  on  the  other 
hand,  probably  sees  a  car  as  the  sum  of  its  parts  -  parts  that  require  maintenance  and 
replacement.  The  object-oriented  approach  is  a  close  approximation  to  these  human  views 
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of  the  world.  It  is  for  this  reason  that  object-oriented  abstraction  techniques  are  generally 
considered  to  be  more  powerful  than  those  of  the  traditional  data  models. 

The  OODM  thus  provides  the  design  mechanisms  with  "vAbich  to  model  diverse  and 
sophisticated  applications  in  a  natural  way.  In  a  larger  sense,  within  the  context  of  overall 
database  development,  the  object-oriented  approach  reflects  a  move  toward  an 
“intelligent”  DBMS  that  directly  supports  advanced  data  modeling.  Li  such  a  system, 
semantic  correctness  remains  intact  from  abstraction  to  in^lementation.  The  burden  of 
translation  is  lifted  from  the  user. 

The  object-oriented  paradigm  remains  the  focus  of  the  active  research.  While 
researchers  and  developers  agree  on  the  underlying  piinc^les,  the  exact  nature  and 
direction  of  the  object-oriented  approach  is  at  present  an  issue  of  debate.  Consequently,  a 
final  and  irrefiitable  definition  for  the  OODM  has  not  yet  been  forwarded.  Despite  the 
evohitionaiy  condition  of  the  OODM,  the  motivation  to  preserve  a  direct  correspondence 
between  real-world  entities  and  their  database  representations  warrants  its  use.  The 
EWIRDB  is  an  ideal  candidate  for  object-oriented  modeling. 

In  this  chapter,  I  present  the  bade  concepts  of  the  OODM.  Because  the  OODM 
was  developed  with  the  ease  of  inq)lementation  in  mind,  some  implementation  issues  are 
also  briefly  addressed.  These  concepts  lay  the  groundwork  for  an  application  of  the 
OODM,  within  the  context  of  both  conceptual  and  logical  design,  to  a  representative 
portion  of  EWIRDB  data  in  Chapter  IV. 

A.  OBJECTS 

The  object  is  the  basic  element  of  the  OODM,  and  the  conq)onent  that  populates 
the  database.  An  object  corresponds  to  any  entity  in  the  real  world:  ideas,  concepts, 
people,  events,  places,  physical  stractures,  and  time  to  name  a  few.  The  uniform 
application  of  objects  to  model  the  spectrum  of  real-world  aitities  siirplifies  flie  designer’s 
view  of  the  real  world  [4]  and  infuses  some  consistency  into  the  designer’s  task. 
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Li  an  object-oriented  database  management  ^stem  (OODBMS),  an  object  is 
specified  with  a  unique,  system-generated  marker  called  the  object  identifier  (OID).  The 
OID  is  immutable,  or  permanent  and  unchangeable  [2].  This  is  an  in^ortant  aspect  of  the 
OODM  from  a  modeling  and  in^lementation  point  of  view.  The  use  of  OID’s  effectively 
decouples  the  object  existence  from  the  object  value.  An  objects  can  therefore  be 
referenced  via  the  OID,  indq)endent  of  an  identifying  value.  Two  objects  with  different 
OID’s  remain  distinct,  even  if  the  two  objects  have  the  same  values.  In  traditional  models, 
on  the  other  hand,  the  identities  of  data  items  are  vahie-based.  The  cumbersome  task  of 
creating  and  managing  unique  identifiers  (called  keys  traditionally)  is  therefore  imposed  on 
the  application  programmer.  Consequently,  meaningful  keys  are  likely  long  and  non¬ 
unique,  and  the  management  of  key  values  is  carried  out  external  to  the  DBMS.  The 
effect  is  a  degradation  in  database  performance. 

The  hierarchical  model  of  the  EWIRDB  is  vahie-based  and  therefore  subject  to 
these  shortcomings.  Specifically,  data  items  referenced  by  application  programs  steer 
through  an  identification  scheme  that  includes  the  ELNOT  and  a  burdensome  hierarchical 
labeling  network.  For  a  given  ELNOT,  or  equivalently  for  a  given  emitter,  a  data  record 
is  uniquely  identified  by  a  suffix  code/tree  number/source  combination  [1].  In  an  object- 
oriented  EWIRDB,  a  data  object  is  uniquely  identified  by  a  system-maintained  OID. 

The  OODM  also  provides  for  the  creation  of  objects  of  arbitrary  conqilexity  [2]. 
The  internal  structure  of  objects  is  thus  sufficiently  adaptable  to  include  all  significant 
information  that  describes  an  entity.  This  internal  structure  is  referred  to  as  the  object’s 
state  and  behavior  [3].  These  a^ects  of  the  OODM  are  addressed  in  the  following 
sections. 

1.  Object  State 

An  object  is  characterized  by  internal  properties  generally  referred  to  as  attributes. 
The  values  of  an  object’s  attributes  define  the  state  of  the  object.  Attribute  values  may 
either  be  simple  or  complex. 
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a.  Simple  Attributes 

Simple  attributes  are  those  whose  values  are  literals  -  character  strings, 
integers,  floating-point  numbers,  and  other  primitive  values.  Typically,  literals  are  not 
considered  as  objects.  For  efficiency  reasons,  they  are  usually  represented  directly  or  are 
self-identifying,  and  not  associated  with  OID’s  [4]. 

b.  Complex  Attributes  and  Relationships 

Complex  attributes  are  those  whose  values  are  conq)osed  of  other  objects 
or  groupings  of  values.  There  are  three  kinds  of  conoplex  attributes:  reference  attributes, 
collection  attributes,  and  derived  attributes  [4].  The  first  two  types  provide  for  an 
arbitrarily  deep  or  recursive  nesting  of  objects,  where  the  state  of  an  object  is  described  by 
attributes  whose  values  are  objects  whose  values  may  be  objects  as  well,  and  so  on.  A 
natiural  representation,  then,  for  the  state  of  an  object  is  a  set  of  OID’s  of  the  objects  that 
are  the  values  of  the  attributes  of  the  object  [3]. 

Reference  attributes  are  the  means  by  which  relationships  between  entities 
are  represented  in  the  OODM.  In  taking  on  object  values,  reference  attributes  e?q)Hcitly 
refer  to,  or  draw  a  relationship  to,  other  entities.  Specifically,  in  the  logical  design, 
reference  attributes  may  be  used  to  model  binary  and  non-binary  one-to-one,  one-to-many, 
and  many-to-many  relationsh^s.  A  relationship  may  be  modeled  in  one  direction,  such  as 
fi:om  an  object  A  to  an  object  B,  where  object  A  refers  to  object  B  but  object  B  contains 
no  such  reference  to  object  A,  or  in  both  directions  throu^  the  use  the  of  an  inverse 
reference  or  irtverse  attribute  [2].  An  inverse  reference  fecilitates  traversal  of  the 
relationship.  The  relationsh^  is  “visible”  to  each  object;  object  A  refers  to  object  B  and 
object  B  refers  to  object  A  inversely.  All  the  relationships  in  which  a  particular  object  type 
participates  are  thus  packaged  within  the  object  itself  in  the  form  of  reference  attributes. 
In  contrast,  a  conq)lete  inspection  of  the  parametric  trees  and  TERF  output  may  be 
required  to  ascertain  the  relationships  that  exist  between  particular  parametric  entities  in 
the  EWIRDB. 
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la  iiiq)leiuentation,  reference  attributes  provide  an  additional  benefit.  They 
cannot  be  corrupted,  ie.  inadvertently  or  maliciously  changed:  the  integrity  of 
relationships  and  references  is  maintained  by  the  OODBMS  throughout  all  database 
operations.  Moreover,  firom  a  modeling  perfective,  because  a  reference  attribute  refers 
to  an  OBD  and  not  a  value,  the  values  encapsulated  within  the  object  to  which  the 
refer«ice  attribute  points  may  be  changed  with  no  effect  on  the  OID,  and  thus  no  effect  to 
the  reference  attribute.  [4]  The  use  of  reference  attribute  has  one  possible  shortcoming, 
however.  Beyond  meaningful  reference  attribute  names,  references  hi  the  OODM  do  not 
imply  any  special  semantics.  Basically,  references  can  only  convey  the  idea  of  an 
association  between  entities. 

Collection  attributes  encoitfass  those  characteristics  of  an  object  that  are 
described  by  more  than  one  value,  or  present  a  couf  lex  arrangement  of  values.  These 
values  are  stored  in  constructors  such  as  lists,  sets,  or  arrays.  The  value  sets,  or  domains, 
from  which  the  values  comprising  the  collection  are  taken  may  contain  anf  le  values  or 
references.  For  example,  a  collection  attribute  may  be  a  set  of  integers  or  a  hst  of  entities 
that  participate  in  a  relationshf  with  the  object. 

Object  properties  that  are  subject  to  frequent  or  regular  modifications,  such 
as  those  that  are  time-based  or  date-based,  are  best  modeled  with  derived  attributes. 
Derived  attributes,  as  the  name  inflies,  are  not  stored  explicitly.  Rather,  they  are  defined 
via  the  execution  of  a  particular  procedure.  A  given  value  for  a  derived  attribute,  and 
therefore  its  storage,  is  teuf  orary  in  nature. 

Except  for  the  brief  introduction  to  derived  attributes,  the  discussion  of 
object  state  to  this  point  has  deah  with  the  static  characteristics,  or  structure  of  an  object. 
The  next  section  addresses  object  characteristics  that  are  dynamic  in  nature. 

2.  Object  Behavior  and  Encapsulation 

An  inf  ortant  aspect  of  the  OODM  is  its  ability  to  incorporate  the  operations  to  be 
applied  to  an  object  of  a  certain  type  into  the  object  itself  The  procedures  that  modify  or 
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return  the  state  of  an  object  in  an  OODBMS  are  called  methods.  The  behavior  of  an 
object  is  thus  defined  by  the  methods  specified  to  act  on  it. 

Methods  are  much  like  programs.  They  are  written  in  a  typical  programming 
language.  A  method  consists  of  two  parts:  an  external  interface  (or  signature)  and  the 
actual  code  to  implement  the  method.  The  external  interfece  defines  the  parameters 
whereby  an  object  interaction  is  recognized.  It  is  the  only  legal  means  by  vsMch  to  invoke 
the  method.  Typically,  the  execution  of  a  method  is  accon5)lished  via  the  message 
passing  [2].  li^  for  exanq)le,  an  object  A  sends  a  properly-parameterized  message  to  an 
object  B  in  order  to  invoke  a  method  in  object  B  that  returns  the  data  stored  in  object  B, 
then  the  method  of  object  B  would  return  the  data  to  requesting  object  A.  This  concept  of 
restricting  access  or  providing  well-defined  access  to  an  object  is  referred  to  as 
encapsulation.  If  strict  encapsulation  is  enforced,  then  the  object  itself  -  its  internal 
structure  and  methods  -  is  accessible  only  via  the  specified  parameters.  The  only  “user- 
visible”  portion  of  the  object  is  the  external  interfiice;  the  data  contained  within  the  object 
and  file  details  of  the  method’s  inq)lementation  are  conqiletely  hidden  firom  external  users. 
Procedures  that  are  visible  outside  the  object  are  public  methods.  An  object  may  also 
encapsulate  private  methods,  or  those  available  only  to  the  object  itself  In  practice, 
however,  strict  object  encapsulation  is  too  restrictive  in  any  OODBMS  [4].  In  addition  to 
file  public  methods,  attributes  may  be  made  visible  as  well 

Encapsulation  is  a  basic  tenet  in  the  OODM.  Its  benefit  is  straightforward: 
encapsulation  permits  a  change  in  the  implementation  of  objects  without  forcing  any 
change  in  the  external  programs  that  use  them  As  long  as  external  interfeces  remain  the 
same,  the  means  to  access  and  man^ulate  objects  remain  the  same.  Provided  the  external 
interface  remains  intact,  it  follows  that  objects  vriiose  structure  has  been  modified  will 
appear  unchanged  to  the  external  world.  Encapsulation  is  also  inq)ortant  in  introducing 
the  concept  of  object  class. 


28 


B.  OBJECT  CLASSES 


A  database  generally  contains  clusters  of  similar  objects.  Each  cluster  contains 
objects  that  encapsulate  the  same  structure  and  behavior,  or  attributes  and  methods.  Just 
as  an  abstract  data  type  is  the  specification  for  a  number  of  data  structures  in  a  typical 
program,  a  class  in  the  OODM  is  the  specification  for  a  number  of  similar  objects  in  a 
database.  A  database  containing  multiple  clusters  of  similar  objects  would  therefore  be 
comprised  of  several  classes.  And  just  as  identically-formatted  data  structures  may 
contain  different  stored  values,  objects  of  similar  structure  and  behavior,  or  objects  in  the 
same  class,  may  exhibit  different  states. 

These  ideas  are  illustrated  in  Figure  6  >^hich  represents  a  small  portion  of  data 
maintained  in  a  fictitious  database  at  NFS.  The  THESIS  class  definition  provides  the 
blueprint  for  creation  of  THESIS  objects.  This  definition  specifies  three  sinq)le  attributes 
-  title,  author,  and  date  of  publication  -  and  two  methods  -  author  bio  and  number 
distributed.  The  method  author  bio  returns  the  author’s  branch  of  service  and  war&e 
specialty  (data  stored  elsewhere  in  the  fictitious  database).  The  method  number 
distributed  returns  for  a  given  thesis  the  number  of  copies  distributed,  a  value  that  may  be 
subject  to  periodic  change.  The  class  THESIS  is  void  of  any  actual  data,  but  the  objects 
of  class  THESIS  contain  values  for  each  q)ecified  attribute  and  invoked  method.  These 
attribute  and  method  values  differ  from  object  to  object;  each  object  of  class  THESIS 
therefore  exhibits  a  different  state. 

Classes  are  the  basic  building  blocks  of  the  object-oriented  modeling.  The  concept 
of  class  is  therefore  the  basis  of  fimdamental  modeling  mechanisms  in  the  OODM.  These 
modeling  mechanisms  are  the  focus  of  this  section.  Some  of  these  mechanisms  are 
considered  to  be  core  concepts  in  the  modeL  The  semantica]ly-m5)ortant  is-instance-of 
relationsh^  is  one.  The  concept  of  gemraUzation-zsA-  specialization  is  another.  Less- 
widely-acknowledged  object-oriented  modeling  concepts  of  aggregation  and  covering  are 
addressed  as  well 
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Figure  6.  An  Object  Oass  and  its  Objects 
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In  addition  to  its  value  in  the  data  modeling,  the  class  concept  has  in:q>oitant  and 
fevorable  consequences  in  implementation.  When  viewed  as  the  collections  of  their 
instances  rather  than  as  the  specifications  of  individual  objects,  classes  form  the  logical 
basis  for  the  formulation  of  queries  [5].  Further,  because  attribute  and  method 
q)ecifications  common  to  objects  of  the  same  class  are  stored  as  a  class  object,  there  is  no 
need  to  repUcate  the  common  information  in  each  object  of  the  class.  The  effect  has 
considerable  savings  in  storage  space.  Finally,  the  class  concept  provides  a  degree  of 
“type  checking”  throu^out  a  class  composition  hierarchy  [3].  The  class  conq>osition 
hierarchy  is  the  direct  result  of  the  recursive  nesting  of  objects  as  attribute  values,  an  idea 
introduced  in  section  in.A.l.b.  These  objects  are  restricted  in  their  values  by  then- 
respective  class  specifications.  In  this  sense,  the  class  is  analogous  to  the  traditional 
notion  of  attribute  domain.  Just  as  the  domain  defines  legal  values  or  types  for  a  given 
attribute,  the  class  defines  the  legal  values  for  a  particular  object  of  that  class.  The  class 
thus  provides  a  degree  of  type  checking  for  an  attribute  whose  value  is  an  object. 

With  the  OODM  concepts  of  the  object  and  the  class  as  building  blocks,  the 
following  sections  detail  the  design  abstractions  applied  to  the  proposed  object-oriented 
design  of  EWIRDB  data. 

1.  Instantiation  and  Classification 

The  class  itself  is  an  object,  void  of  actual  data.  Thus,  it  is  also  termed  the  class 
schema.  It  fimctions  as  the  “blueprint”  with  vriiich  to  generate  objects  of  the  same  class. 
Viewed  in  this  li^t,  an  object  based  on  the  blueprint  of  a  given  class  can  be  thought  of  as 
an  instance  or  an  occurrence  of  that  class.  Since  a  class  contains  the  definition  of  a  set  of 
objects,  it  is  also  an  abstraction  mechanism  [5].  The  class  abstraction  is  rooted  in  the 
complementary  semantic  modeling  concepts  of  instantiation  and  the  classification 

The  instantiation  is  the  process  of  creating  objects  within  the  parameters  of  a  given 
class  schema.  Classification  is  the  inverse  of  instantiation.  It  is  a  process  of  systematically 
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assigning  objects  of  similar  structure  and  behavior  to  their  respective  object  classes. 
Classification  pmuits  the  modeling  of  common  characteristics  that  apply  to  all  of  the 
objects  in  the  class. 

Because  its  a  single  blueprint  from  which  many  objects  may  be  created  and 
catalogued,  the  class  structure  may  be  reused  as  required  to  instantiate  many  smular 
objects.  In  Figure  6,  the  blueprint  for  the  class  THESIS  is  used  three  times  to  instantiate 
each  of  the  three  THESIS  objects  shown.  For  this  reason,  iustantiation  and  clas^cation 
are  collectivefy  considered  to  be  the  first  reusability  mechanism  of  object-oriented  design. 
Inheritance,  addressed  in  the  next  section,  is  the  second  such  mechanism 

2.  Generalization  and  Specialization 

Inheritance  among  classes  produces  class  hierarchies  that  characterize  the  OODM 
abstraction  concepts  of  the  generalization  and  the  specialization.  In  an  inheritance 
hierarchy,  a  class  referred  to  as  the  subclass  inherits  the  stmcture  and  behavior  of  another 
class  called  the  superclass.  In  addition  to  its  inherited  characteristics,  the  subclass  may 
encapsulate  attributes  and/or  methods  not  contained  in  the  superclass.  These  distinct  . 
additions  to  the  subclass  differentiate  it  fiom  the  superclass  and  identify  the  subclass  as 
worthy  of  a  class  status  all  its  own.  In  the  hierarchy,  a  subclass  is  viewed  as  a 
q)ecialization  of  its  superclass.  Likewise,  a  superclass  can  be  perceived  as  the 
generalization  of  those  subclasses  (from  one  to  many)  participating  in  the  inheritance 
hierarchy.  Collectively,  the  concepts  of  generalization  and  socialization  are  equivalent  to 
the  is-a-kind-of  relationship.  If  an  indq)endent  and  unique  subclass  XI  inherits  the 
attributes  and  methods  of  a  superclass  X,  then  XI  may  be  considered  “a  kind  of’  X. 

A  data  hierarchy  based  on  the  inheritance  is  natural  and  well-defined,  unlike 
hierarchies  based  on  arbitrary  and  coded  tree  structures,  such  as  those  found  in  the 
EWIRDB.  Inheritance  enq)hasizes  both  the  commonality  and  the  uniqueness  among 
classes.  Moreover,  the  inq)lementation  of  an  inheritance  (ie.,  a  generalization  and  a 
Socialization)  as  a  mapping  from  class  to  another  class  eliminates  data  duplication  and 


32 


localizes  the  management  of  common  data.  It  is  for  this  last  reason  that  inheritance  is 
touted  the  second  reusability  mechanism  of  object-oriented  design. 

3.  Aggregation 

The  aggregation  abstraction  considers  a  con^oshe  object  as  the  sum  of  its  parts. 
It  is  not  restricted  to  an  object  as  an  aggregation  of  its  attributes.  The  term  is  primarily 
meant  to  represent  an  object  as  an  aggregation  of  other  objects,  ie.,  a  con^osite  object  as 
the  sum  of  its  conq)onent  objects.  The  semantics  are  coirqparable  to  those  of  the  is-a-part- 
of  relationship,  where  an  entity  is  the  grouping  of  its  con:q)onents. 

The  objects  of  component  classes  partic^ating  in  the  aggregation  each  have  their 
own  state.  Likewise,  each  object  of  the  con^osite  class  e^bits  its  own  state.  But  the 
state  of  the  corq)osite  object  in  a  given  aggregation  is  dependent  upon  the  states  of  its 
conq)onent  objects.  A  coirposhe  object  thus  contains  a  “global”  type  of  structure  and 
behavior  that  reflects  the  conq)osite  state  of  its  con:q)onent  parts. 

Singly  drawing  a  relationship  between  an  object  and  its  aggregates  is  not 
semantically  suffident;  it  does  not  capture  the  dependency  between  the  con^osite  object 
and  its  con^onents.  From  an  inq)lementation  point  of  view,  a  relationsh^  will  not 
maintain  the  mtegrity  of  the  aggregation,  or  the  interactions  within  the  aggregation, 
throughout  all  possible  database  operations.  In  particular,  an  operation  on  the  conq)osite 
object  should  affect  component  objects.  Conversely,  an  operation  on  a  conq)onent  object 
should  affect  the  con:q)Osite  object.  The  deletion  of  a  conq>osite  object,  for  exan^le, 
should  cause  deletion  of  all  coroponents  of  the  object.  The  aggregation  and  the  notion  of 
a  composite  object  can  also  be  used  as  the  basis  for  the  clustering  of  data  [4]. 

The  aggregation  abstraction  is  an  inq)ortant  semantic  concept  in  the  OODM.  It  is 
a  design  concept  not  found  in  other  models. 
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4.  Covering 

The  covering  abstraction  is  accepted  as  a  fundamental  concept  in  the  OODM 
within  the  European  community.  It  adds  a  dimenaon  of  flexibility  in  the  modeling  and 
manipulation  of  data.  The  covering  terminology  is  as  followsi  class  X  covers  class  Y  if 
every  object  in  class  X  corresponds  to  a  subset  of  objects  in  class  Y.  These  subsets  of  Y 
need  not  partition  Y;  they  are  certain  subsets  of  all  the  subsets  generated  for  the  objects  of 
Y.  Mathematically,  all  the  subsets  of  Y  form  the  power  set  of  Y,  ie.,  P(Y).  The 
correspondence  is  a  mapping  f  v4iich  determines  for  an  object,  x,  firom  class  X  all  the 
objects,  y’s,  of  the  subset  f(x)  fi:om  class  Y,  such  that  J9^x)  =  y  for  every  one  of  those  y’s 
Class  X  is  referred  to  as  the  cover  class  and  class  Y  is  called  the  member  class.  [6] 

A  covering  relationship  thus  corresponds  an  object  of  one  class  to  a  subset  of  the 
power  set  (the  set  of  all  subsets)  of  objects  of  another  object  class.  It  is  therefore  an 
object-to-object-set  mapping. 

A  single  and  practical  exarcj^le  involving  a  team  and  its  players  is  useftd  in 
describing  the  covering  relationship  between  two  classes.  In  this  example,  the  team  class 
covers  the  player  class.  The  team’s  existence  is  entirely  dependent  on  the  partic^ation  of 
its  players,  a  type  of  existence  dependency.  While  a  team  object  has  its  own  structure  and 
behavior,  its  real  value  is  derived  firom  its  encapsulation  of  the  nature  of  a  particular  set  of 
players  that  corrprise  the  team.  Further,  a  team  object  may  be  operated  on  as  a  single 
object  or  as  a  set  of  player  objects.  And  as  is  generally  the  case  in  the  real-world,  the 
elimination  of  a  team  (object)  does  not  necessarily  entail  the  demise  of  its  players. 

The  covering  is  a  valuable  abstraction  mechanism,  specific  to  the  OODM,  that 
accurately  models  entities  of  the  real  world. 
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IV.  A  CONCEPTUAL  OBJECT-ORIENTED  EWIRDB 


Li  this  chapter,  I  apply  the  princ^les  of  the  OODM,  as  presented  in  Chapter  DI,  to 
develop  a  genuine  concq)tual  design  for  the  EWIRDB.  My  intent  is  not  to  redefine  the 
kinds  of  data  required  to  characterize  an  emitter’s  performance;  the  existing  EWIRDB 
data  herns  have  sound  scientific  roots.  Nor  do  I  attenq)t  to  address  every  existing  data 
element  in  the  EWIRDB.  My  goal  is  to  justify  the  proposhion  that  the  object-oriented 
approach  is  feasible  for  the  EWIRDB  by  providing  a  conceptual  design  of  a  representative 
portion  of  the  database  -  a  portion  that  adequately  reflects  the  nature  of  electronic  warfere 
data.  Diagrams  are  used  at  every  stage  to  codify  flie  conceptual  design.  A  description  of 
the  conceptual  dedgn  symbology  must  first  be  addressed. 

The  absence  of  a  standardized  OODM  introduces  some  variation  in  its 
diagrammatic  representation.  However,  most  of  the  ^rmbology  adopted  in  this  thesis  for 
the  conceptual  deagn  of  the  EWIRDB  is  commonly  used.  Pos^le  exceptions  are  those 
notations  corresponding  to  abstractions  such  as  covering  and  aggregation.  Variations 
aside,  the  consistent  use  of  an  adequately-expressive  symbology  is  all  that  matters. 

The  symbology  used  in  the  conceptual  design  of  the  EWIRDB  are  drown  in  Figure 
7.  The  inherhance  abstraction  as  h  appears  in  Figure  7  includes  some  detail  not  previously 
addressed.  The  concept  of  overlapping  inheritance  stipulates  that  an  object  of  the 
superclass  (generalization  class)  may  be  a  member  of  more  than  one  subclass  of  the 
specialization.  Disjoint  inheritance  states  that  an  object  of  the  superclass  may  be  a 
member  of  at  most  one  subclass  of  the  specialization.  Regardless  of  the  type,  however, 
each  inheritance  hierarchy  in  the  conceptual  design  of  the  EWIRDB  is  a  total 
specialization.  This  idea  states  that  every  object  of  a  superclass  must  be  a  member  of 
some  subclass  in  the  given  inheritance  hierarchy[2]. 
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The  representation  of  relation^ps  requires  anq)]ification  as  well.  Figure  7 
includes  a  description  of  the  participation  constraints  in  relationships  between  the  objects 
of  partic^ating  classes.  A  total  participation  constraint  indicates  that  for  the  class  of 
objects  whose  participation  in  a  given  relationsh^  is  total,  the  very  existence  of  that  class 
of  objects  depends  on  its  participation  in  the  relationsh^.  For  exan:q)le,  in  a  relationship 
between  common  entities  such  as  tran^ortation  vehicles  and  license  plates,  the 
participation  of  license  plates  would  be  total;  hcense  plates  are  unnecessary  if  there  are  no 
vehicles  to  license.  Ergo,  the  existence  of  license  plates  depends  on  tiie  relationship 
between  cars  and  license  plates.  A  partial  participation  constraint,  in  contrast,  states  that 
all  objects  of  a  particular  class  need  not  participate  in  a  given  relationship.  In  a 
relationship  between  married  couples  and  children,  for  instance,  not  all  married  couples 
have  children.  The  participation  of  married  couples  in  the  relationship  is  therefore  partiaL 
Participation  constraints  are  an  important  aspect  of  conceptual  modeling.  They  fiuther 
characterize  the  nature  of  data  relationsh^s. 

A.  A  GLOBAL  SCHEMA 

The  EWIRDB  was  described  earlier  (Figure  1)  as  the  adnunistrative  merging  of 
data  from  three  contributory  sources.  Now,  a  global  and  object-oriented  view  of  the 
merged  structure  of  the  EWIRDB  is  provided  in  Figure  8  with  the  use  of  aggregation 
semantics.  The  ‘big  picture”  object-oriented  view  of  the  EWIRDB  in  Figure  8  is  largely 
administrative.  It  may  at  first  seem  strange  to  proceed  hi  this  manner,  to  initially  approach 
the  modeling  task  from  an  administrative  rather  than  technical  point  of  view,  especially  in 
li^t  of  the  technical  nature  of  emitter  data.  But  this  approach  is  valid.  As  explained  k 
Chapter  1,  the  data  items  that  describe  an  emitter  retak  the  formatting  particular  to  the 
database  from  \^bich  they  were  contributed.  In  a  global  view,  source- specific  groupkgs 
of  data  herns  are  assigned  group-specific  administrative  labels.  A  design  that  proceeds 
whhk  an  administrative  context  preserves  these  important  assocktions. 
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Figure  8.  The  Conceptual  Schema:  A  Global  View 
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As  a  result  of  the  merging,  the  data  items  contributed  by  each  source  to  describe  a 
particular  emitter  may  overlap.  Moreover,  each  source  may  contribute  mult^le  value 
entries  for  a  ^en  data  item  But  the  identity  of  each  data  entry  remains  intact.  Multiple 
entries  for  a  given  data  item  are  not  “fused”  together  to  form  a  single  EWIRDB  entry. 
Each  data  item  remains  separate  and  distinct,  in  a  form  that  is  suggestive  of  its  source. 
Approaching  the  conceptual  design  from  an  administrative  bias  thus  ensures  that  the 
overall  structure  of  the  database  as  a  collection  of  emitter  data  from  mult^le  sources  will 
be  accurately  reflected  in  the  object-oriented  schema. 

In  Figure  8,  the  aggregates  KILTING  EMITTER,  S&H  EMITTER,  and 
USNCSDB  EMITTER  combine  to  form  the  con:Q)osite  EMITTER  class  of  objects. 
This  aggregation  precisely  models  the  multi- source  stracture  of  the  database.  As  the 
conqposite,  an  EMITTER  object  represents  the  merging  of  all  data  for  a  given  emitter. 
Each  aggregate,  on  the  other  hand,  represents  a  source-^edfic  portion  of  the  data  in  the 
conjposite.  The  aggregate  KILTING  EMITTER  encapsulates  Kilting  technical  data 
contributed  to  the  EWIRDB  for  a  given  emitter.  The  S&TI  EMITTER  aggregate 
encapsulates  the  technical  data  contributed  from  S&TI  centers,  and  the  USNCSDB 
EMITTER  aggregate  encapsulates  USNCSDB  data  for  a  given  emitter. 

With  aggregation  semantics,  emitter  parametric  data  may  be  reasoned  about  on 
two  levels  of  abstraction;  in  the  conq)osite,  dealing  with  all  available  data,  or  on  the 
aggregate  (conq)onent)  level,  where  the  data  from  a  particular  contributory  source  is 
considered  singularly.  This  adds  a  degree  of  flexibility  in  the  manipulation  of  data  that 
may  not  be  achievable  in  more  conventional  models.  Further,  categorizing  emitter  data  by 
source  is  appropriate  because  it  allows  the  drawing  of  relationships  between  source- 
q)ecific  administrative  data  and  the  aggregates  themselves.  In  Figure  8,  each  aggregate 
participates  in  a  1:1  relationship  with  an  administrative-data  class  of  objects;  KILTING 
EMTITER  with  KILTING  ADMINISTRATIVE  DATA;  S&Tl  EMITTER  with 
S&TI  ADMINISTRATIVE  DATA;  and  USNCSDB  EMITTER  with  USNCSDB 
ADMINISTRATTVE  DATA.  The  participation  of  each  administrative  data  class  in  its 
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respective  1:1  relationsih^  is  total  because  the  existence  of  an  administrative  data  class 
depends  solely  on  the  viability  of  the  relationship.  for  instance,  the  Kilting  database 

contributed  no  data  to  the  EWIRDB  for  a  given  emitter,  then  for  that  given  emitter,  the 
KILTING  EMIITER  class  of  objects  would  be  undejBned.  In  effect,  KILTING 
EMITTER  would  be  non-existent,  as  would  any  relationdi^  in  which  it  participated.  In 
this  example,  the  existence  of  the  KILTING  ADMINISTRATIVE  DATA  class  of 
objects  would  be  meaningless  as  well 

As  mentioned  in  Chapter  I,  the  formatting  for  S&TI  and  USNCSDB  data  are  the 
same.  The  attributes  in  the  related  administrative  data  classes  are  also  the  same.  The 
attribute  values,  however,  are  likely  different  between  the  two  classes.  This  does  not  rule 
out  the  possibility  that  some  or  all  of  the  values  may  be  identical.  But  the  possibility, 
likely  or  not,  that  the  attribute  values  may  differ  depending  on  the  source  necessitates  the 
appearance  of  the  same  attributes  in  both  classes.  For  the  same  reason,  the  attributes 
classification  and  releasability  are  duplicated  in  all  three  administrative  data  classes. 
This  seems  to  contradict  object-orientation,  wherein  commonality  is  fectored  out  among 
similaT  classes  to  form  a  superclass.  However,  because  the  attribute  values  may  possibly 
be  different  from  class  to  class,  the  common  attributes,  by  virtue  of  their  values,  still 
function  to  differentiate  the  classes,  bi  these  particular  situations,  the  semantics  of 
generalization  sinqrly  do  not  apply  and  the  same  attribute  values  may  appear  in  each  class. 

The  EWIRDB  ADMINISTRATIVE  DATA  class  contains  methods  to  extract 
information  from  the  source-specific  classes  in  the  schema.  These  methods  retrieve 
administrative  data  for  a  given  emitter  that  in  turn  define  the  administrative  state  of  all 
merged  emitter  data.  An  object  of  the  class  EWIRDB  ADMINISTRATIVE  DATA  may 
reflect  data  retrieved  from  more  than  one  class  of  the  schema.  The  method  overall 
classification  returns  the  hipest  classification  from  among  the  source-specific 
administrative  data  classes;  it  defines  the  classification  or  the  conqiosite  classification  for  a 
given  emitter.  Althou^  not  at  present  an  attribute  e?q)licitly  accounted  for  in  the 
EWIRDB,  the  method  overall  releasability  was  included  to  satisfy  the  requirement  that 
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“...The  releasability  and  handling  caveats  reflect  a  merger  of  the  three  sources...  ”[1]  This 
method,  like  the  first,  returns  the  most  stringent  of  the  releasability  instractions  and  thus 
defines  the  releasability  for  the  data  of  a  given  emitter  when  the  data  are  considered  in  the 
conq)o^e.  The  method  parametric  update  searches  throu^  all  the  class  attributes  in 
the  database  for  a  given  emitter  and  returns  the  latest  data  update  date.  The  effect  is  an 
EWIRDB  ADMINISTRATIVE  DATA  class  that  describes  the  con5)Osite  EMITTER 
class  of  objects.  EWIRDB  ADMINISTRATIVE  DATA  therefore  partic^ates  in  a  1:1 
relationship  with  EWIR  EMITTER.  And  like  the  source-q)ecific  administrative  data 
classes,  its  participation  in  the  relationship  is  total. 

In  Figure  8,  the  attribute  ELNOT  in  the  EMITTER  class  is  a  kind  of  social 
security  number  for  emitters.  It  uniquely  identifies  an  emitter,  or  more  precisely,  the  signal 
that  is  characteristic  of  an  emitter.  ELNOT  is  an  important  attribute  because  it  is  the 
primary  means  of  emitter  identification,  and  may  often  be  the  launch  point  for  EWIRDB 
queries.  The  attribute  color  is  an  appropriate  addition  to  EMITTER  because  it  describes, 
in  general,  an  emitter’s  role  in  terms  of  fiiendly  or  hostile  use.  The  choice  of  attribute 
values  are  “blue”  for  those  emitters  aboard  US  military  platforms,  “blue/gray”  for  those 
originally  in  US  production  that  were  legitimately  transferred  to  Rest  of  World  (ROW) 
coimtries  (non-US,  non-Communist),  “gray”  for  emitters  aboard  non-Communist  country 
platforms,  and  “fed”  for  emitters  produced  by  Communist  countries  [guide].  The  attribute 
color  thus  provides  a  big  picture  look  at  an  emitter.  Because  it  is  not  a  source-specific 
characteristic,  it  is  best  placed  in  the  composite  class. 

The  global,  object-oriented  view  of  the  EWIRBD  presented  in  Figure  8 
incorporates  all  the  data  eluents  contained  in  the  SOO  and  SOI  records  in  the  TERF 
output.  The  S&TI  Code  found  in  SOI  records  (Figure  5)  is  included  in  both  the  S&TI 
ADMINISTRATIVE  DATA  and  USNCSDB  ADMINISTRATIVE  DATA  classes.  It 
therefore  applies  to  all  assessed  data  encapsulated  within  an  instantiation  of  S&TI 
EMITTER  or  USNCSDB  EMITTER.  The  dupUcate  S&TI  Code  entry  found  in  S03 
records  (Figure  5)  is  removed  from  any  fiuther  consideration. 
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Object-orientation  eliminates  the  need  for  S02  branch  information.  The  S02  data 
ftlpmftnt  Technical  Date  (Figure  5),  however,  specific  to  Kilting  emitter  data,  is  included 
as  a  method  in  the  KILTING  ADMINKTRATIVE  DATA  class.  Similar  to  the  method 
parametric  update,  this  method  returns  a  date  that  indicates  the  latest  update  to  emitter 
data,  but  applies  to  smaller,  more  specific  groups  of  data.  These  groups  are  collections  of 
generally  related  data  elements,  referred  to  in  this  thesis  as  logical  groupings.  Logical 
groupings  are  introduced  in  section  B  and  elaborated  in  section  C. 

The  benefit  of  object-orientation  is  a  more  coherent  and  intuitive  design.  Now,  for 
a  given  emitter,  administrative  and  technical  emitter  data  are  encapsulated  within  the 
EMITTER  class  via  aggregation,  relationidiips,  and  inheritance.  To  this  point  in  the 
conceptual  deagn,  particularly  firom  the  administrative  point  of  view,  the  presentation  of 
data  is  clearer  than  that  found  in  the  parametric  tree-TERF  model. 

B.  THE  EMITTER  SCHEMAS 

The  next  step  in  the  development  of  the  conceptual  design  focuses  on  the  technical 
aspect  of  emitter  data  and  addresses  the  data  encapsulated  within  the  classes  KILTING 
EMHTER,  S&TI  EMIITER,  and  USNCSDB  EMIITER. 

To  reiterate,  the  conceptual  designs  presented  m  this  section  are  based  on  portions 
of  the  EWIRDB.  These  portions  are  sufficiently  representative  of  the  entire  database  and 
accurately  reflect  the  nature  of  EW  data.  Because  the  focus  of  this  section  is  the  overall 
organization  of  emitter  parametric  data,  the  detail  of  object  structure  and  behavior  is 
omitted.  (Specific  class  attributes  are  provided  in  Chapter  V  as  part  of  the  logical  design.) 
This  does  not,  however,  take  away  from  the  intended  semantics,  and  the  schematics  reveal 
the  utility  of  the  object-oriented  approach  in  providing  a  unified  and  intuitive  picture  of 
emitter  parametric  data. 
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1.  The  Kilting  Emitter  Qass 

The  overall  configuration  of  the  data  encapsulated  within  the  aggregate  KILTING 
EMITTER  class  is  depicted  in  Figure  9.  An  emitter  object  is  not  described  as  the 
con:q)Osite  of  its  coBcqponent  parts,  ie.,  an  aggregation.  Modeled  as  an  aggregation,  the 
analysis  of  con5)lex  EW  emitters  could  then  be  one  of  a  hardware-oriented  divide-and- 
conquer.  An  overall  performance  assessment  could  be  made  based  on  the  intermediate 
results  obtained  in  the  evaluation  of  the  hardware  conq)onents.  But  the  hardware 
conq)onents  themselves  are  not  central  to  the  discussion  of  EW.  For  the  purposes  of  the 
EWIRDB,  hardware  con^onents  are  only  inqiortant  in  that  they  have  some  effect  on,  or 
participate  in  the  generation  oJ^  a  given  signal  The  signal  itself  is  pivotal  in  the  analysis  - 
not  the  hardware.  This  is  reflected  in  the  design  shown  in  Figure  9.  Rather  than  being 
exposed  hardware  component  by  hardware  component,  the  KILTING  EMITTER  class 
of  objects  is  instead  related  to  several  logical  groupings  of  data,  all  of  which  are  signal- 
based  in  their  descr^tion  of  enutt^  performance. 

KILTING  EMITTER  partic^ates  in  a  one  to  many  relationship  with 
ANTENNA,  a  class  that  encapsulates  a  logical  grouping  of  antenna-signal  data.  A  single 
emitter  may  contain  one  or  more  antennas,  each  of  which  may  have  a  different  function  or 
produce  a  different  effect  on  a  agnal  However,  antenna  hardware  is  not  explicitly 
addressed  within  the  antenna-data  grouping.  Modeling  the  relationshp  between 
KILTING  EMITTER  and  ANTENNA  as  one-to-many  is  not  intended  to  treat  this 
portion  of  EWIRDB  data  as  hardware  oriented,  althou^  this  may  be  a  collateral  effect. 
More  mportant  is  the  effect  of  any  given  antenna  on  an  emitter’s  signal  The  one-to-many 
relationship  reflects  the  &ct  that  that  there  may  be  muh^le  antennas,  or  multiple  versions 
of  antenna  data  for  a  particular  emitter,  dqiending  on  the  number  of  antennas  and  the 
availability  of  information  on  each.  The  antenna  data  grouping  is  given  more  detailed 
treatment  in  section  C.  1. 
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F^ure  9.  The  Conceptual  Schema:  Kilting  Emitter  Data 


KILTING  EMITTER  paitic^ates  in  a  one-to-many  relationship  with  the  class 
SIGNAL,  perhaps  the  most  in:q)ortant  grouping  of  data  in  identifying  an  emitter  and  its 
signal  signature.  The  one-to-many  relationship  indicates  that  an  emitter’s  identifying 
signal  is  subject  to  variation.  A  change  in  the  configuration  of  the  emitter’s  controls,  for 
exan5)le,  causes  a  variation  in  the  signal.  Therefore,  an  emitter’s  signal  may  behave 
differently,  with  respect  to  fimdamental  signal  characteristics,  depending  on  the 
en]ployment  of  the  emitter.  Signal  characteristics  are  described  in  section  C.2. 

KILTING  EMITTER  also  participates  in  a  one-to-many  relationsh^  with  the 
WARM  (Wartime  Reserve  Mode)  class,  which  encapsulates  those  signal  characteristics 
likely  to  be  encountered  only  when  an  emitter  is  in  a  wartime  reserve  mode.  A  single 
emitter  may  have  from  zero  to  many  such  special  modes.  Wartime  reserve  modes  are 
those  emitter  capabilities,  deliberately  held  in  reserve,  that  differ  from  or  exceed  normal- 
use  capabilities.  WARM’S  are  used  exclusively  in  emergency  or  wartime  scenarios  to 
counter  attenq)ts  to  exploit  the  perceived  weaknesses  in  an  emitter’s  performance.  A 
sound  assessment  or  a  foreknowledge  of  the  WARM’S  eooployed  by  an  enemy  can  be  a 
huge  advantage  in  the  prosecution  of  EW.  WARM  data  is  therefore  an  in^ortant  aspect 
of  the  EWIRDB. 

To  provide  for  a  sinQ)lified  diagrammatic  layout,  the  WARM  class  is  surrounded 
by  a  circle  to  represent  the  existence  of  a  digoint  inheritance  hierarchy.  WARM  data  is 
examined  more  closely  in  section  C.4. 

Finally,  KILTING  EMITTER  objects  have  a  one-to-one  relationship  with  the 
SUFFIX  TABLE  class  of  objects.  The  su£Bx  table  as  it  currently  exists  in  the  EWIRDB 
describes  con^lex  emitter  mode  combinations  in  concise  frshion.  Knowledge  of  these 
combinations  allow  EWIRDB  analysts  to  establish  emitter  performance  patterns  and  mode 
usage  tendencies.  The  suffix  table  is  thus  an  in^ortant  tool  that  helps  the  analyst  to 
discriruinate  between  signals  and  ultimately  associate  a  signal  to  an  emitter.  It  is  examined 
more  closely  in  section  C.5. 
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2.  The  Association  of  an  Emitter  to  its  Signal 

Associating  a  unique  signal  to  its  emitter  is  a  difficult  modeling  problem,  object- 
oriented  or  otherwise.  The  assodation  is  characterized  by  an  ELNOT  that  uniquely 
identifies  an  emitter  that  is  uniquely  identified  by  its  signal  signature.  (ELNOT  is  an 
attribute  encapsulated  within  the  EMITTER  class  shown  in  Figure  8.)  More  precisely, 
the  ELNOT  is  “assigned  to  each  noncommunications  emission  for  collection  guidance  and 
reporting  purposes.”[l]  Thus,  the  uniqueness  of  the  ELNOT,  assigned  to 
noncommunications  emissions,  inches  a  one-to-one  relationship  from  signal  to  emitter,  or 
equivalently  from  emitter  to  signal.  This  modeling  is  easy  to  reason  about  in  theory,  but  in 
application,  hard  to  achieve.  In  Figure  9,  the  general  organization  of  the  parametric  data 
describes  an  emitter  by  its  signal  attributes  within  the  context  of  antenna-induced  effects 
(ANTENNA  DATA),  signal  characteristics  in  general  (SIGNAL),  reserve  modes 
(WARM),  and  combinations  of  modes  (SUFFIX  TABLE).  While  this  design  provides  a 
conq)rehensrve  view  of  signal-based  parametric  data,  the  one-to-one  nature  of  the 
relations!]^  between  emitter  and  signal  becomes  obscmred.  Although  the  data  are  more 
semantically  meaningfirl  when  described  within  the  logical  groupings,  tire  effect  is  a 
partitioning  of  the  data.  Consequently,  a  relationsh^  must  be  developed  between  the 
emitter  (KILTING  EMITTER)  and  each  partition.  Several  relationdiips  then  exist  to 
describe  the  relationship  between  emitters  and  signals.  Not  all,  however,  are  one-to-one; 
KILTING  EMITTER  partic^ates  in  a  one-to-many  relationship  with  ANTENNA 
DATA,  SIGNAL  DATA,  and  WARM  DATA.  The  end  result  is  an  association  between 
an  emitter  and  its  signal,  but  the  uniqueness  of  the  relationship  is  directly  modeled  only 
throng  the  use  of  the  ELNOT.  The  ability  of  an  emitter  to  vary  its  signal  characteristics  - 
and  effectively  produce  more  than  one  signal  -  makes  it  more  difficult  to  visualize  the  one- 
to-one  nature  of  the  relationsh^  between  emitter  and  agnal,  and  therefore  between 
ELNOT  and  emitter.  The  one-to-one  relationsh^  remains  intact,  but  is  perhaps  more 
identifiable  because  of  the  existence  of  the  ELNOT. 
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3.  The  S&n  and  USNCSDB  Emitter  Oasses 


As  discussed  in  Chapter  I,  the  S&TI  community  produces  performance 
assessments  based  on  an  e^diaustive  search  of  all  available  hrformation.  These  assessments 
are  particularly  useM  in  developing  an  understanding  of  an  emitter’s  receiver  capabilities. 
USNCSDB  data,  derived  from  equipment  specifications,  also  includes  receiver 
performance  data.  Similar  in  all  other  design  aspects,  the  USNCSDB  and  S&TI 
conceptual  designs  shown  in  Figures  10  and  11  are  the  same. 

In  contrast,  the  KILTING  EMITTER  schema  in  Figure  9  does  not  contain 
receiver  data  because  Kilting  data  reveals  nothing  about  receiver  performance.  Kilting 
data  are  obtained  from  the  direct  analysis  and  measurement  of  emitter  signals  following 
signal  intercept.  An  emitter’s  receiver,  however,  produces  no  obvious  observable  effect. 
The  class  RECEIVER,  which  encapsulates  the  logical  grouping  of  receiver  data  in  both 
Figures  10  and  1 1,  is  similar  to  the  ANTENNA  class  in  that  the  information  it  presents  is 
inq)ortant  in  describing  the  effect  of  hardware  on  any  given  signal.  RECEIVER, 
however,  encapsulates  data  that  tends  to  be  more  hardware-oriented.  The  receiver’s 
fimction  is  to  accept  a  signal,  process  it,  and  then  relay  signal  information  to  a  display. 
A  receiver’s  man^ulation  of  a  signal  is  strictly  internal  and  does  not  dfrectly  produce  an 
effect  that  is  visible  in  the  atmosphere.  The  internal  fimction  of  receivers  in  processing 
signal  data  is  therefore  best  described  within  the  context  of  hardware  conqionents. 

The  one-to-many  relationsh^  between  the  emitter  class  and  RECEIVER  in 
Figures  10  and  11  convey  the  idea  that  an  emitter  may  consist  of  one  or  more  receivers. 
The  receiver  data  grouping  is  given  more  detailed  treatment  in  section  C3. 
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Figure  10.  The  Conceptual  Schema:  S&TI  Emitter  Data 
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Figure  11.  The  Conceptual  Schema:  USNCSDB  Emitter  Data 
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C.  THE  SCHEMAS  WITHIN  LOGICAL  GROUPS 


In  this  section  1  present  a  more  detailed  view  of  the  data  contained  within  the 
logical  data  groupings  described  in  the  previous  section.  Logical  groiq)ings,  like  the 
sub£Q.es  that  currentfy  exist  in  the  EWIRD,  enconq)ass  logically-related  data  elements.  But 
the  schemas  depicted  in  this  section  reinforce  the  notion  that  the  OODM  provides  for  data 
semantics  previously  unachievable  in  the  EWIRDB.  Enq)hasis  is  placed  on  the  schema 
design;  con[q)lete  technical  descriptions  of  each  data  class  are  provided  in  [8]  and  [9]. 
Supplemental  information  is  provided  in  [10]  and  [11]. 

1.  Antenna  Data 

Figure  12  is  an  enlargement  of  antenna-related  signal  data.  It  represents  a 
substantial  irr5)rovement  over  the  semantically  limited  hierarchical  tree  representation  of 
ant^ma  data  discussed  in  section  LB.l.b. 

Specifically,  an  antenna  may  exhibit  a  polarization  and  a  particular  radiation 
pattern,  as  described  by  the  one-to-one  relationship  between  ANTENNA  and 
POLARIZATION,  and  by  the  one-to-one  relationship  between  ANTENNA  and 
RADIATION  PATTERN.  Two  disjoint  hierarchies  branch  out  from  the 
POLARIZATION  class.  One  addresses  the  orientation  of  the  electromagnetic  wave, 
specializing  the  polarization  as  either  linear  or  circular/elliptical.  The  other  desaibes  the 
variation  of  the  polarization  as  either  fixed  or  variable.  Thus,  using  the  tools  of  the 
OODM,  the  four  possible  polarization  combinations  -  fixed-linear,  fixed-circular/ell^tical, 
variable-linear,  variable-drcular/elliptical  -  are  captured  intuitively  in  the  schema.  An 
antenna’s  cross  polarization  characteristics  are  now  correctly  modeled  in  the  one-to-one 
relationship  between  POLARIZATION  and  CROSS  POLARIZATION.  No  longer  are 
cross  polarization  characteristics  confused  with  those  that  determine  an  antenna’s  design 
wave  orientation  or  its  polarization  variation  properties.  Moreover,  access  to  data 
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concerning  an  antenna’s  polarization  also  guarantees  access  to  data  concerning  the 
antenna’s  cross  polarization,  via  the  relationship. 

The  same  is  now  true  for  antenna  data  connected  with  the  VARIABLE 
POLARIZATION  class.  The  classes  ADAPTIVE  POLARIZATION,  MANUAL 
POLARIZATION,  and  PERIODIC  PROGRAMMED  POLARIZATION  in  the 
hierarchies  are  clearly  specializations,  or  types  of  variable  polarization.  The  class 
POLARIZATION  MODULATION,  poshly  mistaken  for  a  type  of  variable 
polarization  in  the  parametric  tree  model,  is  instead  related  to,  and  therefore  descr^tive 
0^  VARIABLE  POLARIZATION  via  the  one-to-many  relationsh^. 

The  remainder  of  Figure  12  provides  a  straightforward  representation  of  other 
aq)ects  of  an  antenna’s  functionality.  An  antenna  may  radiate  directionally  or 
omnidirectionally.  If  the  antenna  is  directional,  then  it  is  associated  with  one  or  more 
scanning  techniques.  The  antenna  scan  data  is  fiirther  refined  within  the  ^ecialization’s 
subordinate  to  the  mechanical  and  electronic  scan  classes.  In  addition,  an  electronically 
scaruning  antenna  may  be  controlled  by  one  or  more  scan  programs,  and  enq)loys  a  beam 
formation  method  to  effect  its  scanning  movement.  A  directional  antenna  also  performs  a 
tracking  fimction,  which  may  include  simultaneous  mechanical  and  electronic  tracking. 
Finally,  the  features  of  electronic  scanning  are  largely  determined  by  one  or  more 
fimctional  scan  programs. 

Figure  12  represents  some  of  the  salient  aspects  of  antenna  data  in  a  way  that  is 
understandable  to  both  expert  and  novice.  This  depiction  of  antenna  data,  in  the  form  of 
the  OODM,  is  clearly  superior  to  that  of  the  arbitrary  tree  model. 

2.  Signal  Data 

Figure  13  depicts  an  enlargement  of  the  logical  grouping  of  signal  data  and 
addresses  the  conqjlexities  of  signal  transmission  in  a  natural  and  intuitive  way.  The 
information  contained  in  this  grouping  details  fimdamental  signal  characteristics. 
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Figure  13.  The  Conceptual  Schema:  Signal  Data  Enlargement 
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Any  given  signal  is  generated  with  a  certain  power  that  is  either  constant  or 
variable  in  nature.  The  object-oriented  representation  exactly  matches  these  semantics. 
SIGNAL  particq)ates  in  a  one-to-one  relationship  with  TRANSMISSION  POWER,  the 
generalization  of  the  specialization  classes,  CONSTANT  POWER  and  NOT 
CONSTANT  POWER.  The  SIGNAL  class  is  the  root  of  the  inheritance  hierarchy  that 
spawns  the  PULSED  RE  (Pulsed  Radio  Frequency)  and  CW  (Continuous  Wave) 
q>ecialization  classes.  PULSED  RE  is  the  basis  of  the  conceptual  schema  in  Figure  13;  it 
is  the  starring  point  in  the  modeling  of  basic  signal  characteristics  such  as  pulse  duration, 
pulse  amplitude,  pulse  repetition  interval  (PRI)  and  pulse  group  repetition  interval  (PGRI), 
and  frequency  (RF).  (CW  signal  characteristics  are  represented  within  the  class  CW  but 
are  not  examined  any  further.) 

For  a  given  occurrence  of  PULSED  RE  there  exists  a  one-to-one  relationsh^  with 
the  classes  PULSE  DURATION,  PULSE  AMPUTUDE,  PRI/PGRI,  and  RE  LINE 
STRUCTURE.  These  classes  characterize  in  detail  the  nature  of  a  given  signal  pulse. 
PULSED  RE  is  a  generalization  class  in  the  inheritance  hierarchy  that  refines  the 
description  of  a  pulsed  signal’s  carrier  firequency.  The  basis  of  specialization  is  the 
constancy  of  the  carrier  firequency.  A  given  pulsed  rignal  therefore  belongs  to  either  the 
RE  CONSTANT  class  or  RE  NOT  CONSTANT  class.  A  subordinate  hierarchy  rooted 
at  RE  NOT  CONSTANT  fiuther  describes  the  nature  of  the  variation  in  the  carrier 
fi-equency. 

Objects  in  the  classes  PULSE  DURATION  and  PULSE  AMPLITUDE  may  be 
static  or  variable,  as  indicated  by  the  specialization  classes  PD  MODULATED  and  PA 
MODULATED,  respectively.  Both  are  single  ^edalizations.  for  instance,  an  object 
of  the  class  PULSE  DURATION  is  not  modulated,  then  there  is  no  information  outside 
of  the  class  PULSE  DURATION  that  is  required  to  describe  that  object.  If  the  intent  is 
to  desaibe  a  modulated  p^llse  duration,  then  additional  or  specialized  data  is  required,  and 
an  object  of  class  PD  MODULATED  would  be  instantiated. 
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Objects  of  the  class  PRI/PGRI  belong  to  either  the  CONSTANT  PRI/PGRI 
specialization  class  or  the  NOT  CONSTANT  PRI/PGRI,  depending  on  the  pulse-to- 
pulse  changes  in  pulse  interval  A  member  of  the  NOT  CONSTANT  PRI/PGRI  reflects 
interval  changes  that  are  either  discrete  or  continuous.  The  classes  DISCRETE  and 
CONTINUOUS  are  themselves  gen^alizations  in  overlapping  inheritance  hierarchies. 
Additionally,  a  pulsed  signal  t^^ose  piilse  repetition  interval  is  not  constant  exhibits  the 
characteristics  of  some  type  of  interval  scheduling  control  A  one-to-one  relationship 
therefore  exists  between  NOT  CONSTANT  PRI/PGRI  and  the  class  INTERVAL 
SCHEDULING.  An  interval  scheduling  control  induces  one  or  more  recurrent  pulse 
repetition  intervals.  The  schema  therefore  includes  a  one-to-many  relationdi^  between 
INTERVAL  SCHEDULING  CONTROL  and  the  class  RECURRENT  INTERVALS. 
The  RECURRENT  INTERVALS  class  is  in^ortant  in  its  description  of  recurrent 
interval  sequences;  it  may  be  thou^t  of  as  a  hi^er  level  abstraction  for  an  arrangement  of 
interval  sequences.  Moreover,  it  becomes  meaningless  as  an  abstraction  without  the 
existence  of  interval  sequences.  Viewed  in  this  way,  a  mapping  may  be  developed 
between  recurrent  interval  an  recurrent  interval  sequences.  In  Figure  13  this  mapping  is 
represented  as  a  covering;  cover  class  RECURRENT  INTERVALS  covers  the  member 
class  RECURRENT  INTERVAL  SEQUENCES. 

3.  Receiver  Data 

Aggregation  semantics  model  the  hardware-orientation  of  the  receiver  data.  In 
Figure  14,  the  class  RECEIVER  is  the  “outermost”  conposhe  in  a  nested  aggregation 
wherein  some  of  a  receiver’s  aggregates  are  themselves  conq)osites  that  are  conq)osed  of 
aggregates.  Objects  that  belong  to  the  classes  IF  PREAMPLIFIER  and  IF 
AMPLIFIER,  for  exanq>le,  are  aggregates  of  objects  of  the  class  INTERMEDIATE 
FREQUENCY  SECTION.  Objects  of  the  class  INTERMEDIATE  FREQUENCY 
SECTION  are,  in  turn,  aggregates  of  objects  of  the  class  RECEIVER. 
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Figure  14.  The  Conceptual  Schema:  Receiver  Data  Enlargement 
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Thus,  RECEIVER  represents  the  sum  total  of  all  con^onents  that  function 
together  to  perform  the  receiver  task.  More  precisely,  receiver  functionality  and 
conq)onent  functionality,  not  hardware,  is  the  baas  of  the  aggregation.  The  specifics  of 
the  hardware  is  inq)ortant  only  in  drawing  boundaries  between  functional  sections  of 
conq)onents  that  are  common  to  all  receivers.  And  despite  hardware  diflferences,  all 
receivers  may  be  modeled  in  this  way  because  of  a  similar  fimctionality.  This  is  a  logical 
and  natural  representation  of  the  data.  The  receiver  portion  of  an  emitter  may  now  be 
reasoned  about  in  general  terms  as  a  singular  miit  and,  or  exposed  in  more  detail  as  the 
aggregation,  or  nested  aggregation,  of  distinct  functional  sections. 

Many  of  the  actions  performed  by  a  receiver  are  described  as  either  single  pulse 
processing  or  mult^le  pulse  processing.  These  labels  can  be  assigned  to  receiver 
processes,  within  the  setting  of  aggregation  semantics,  as  shown  in  Figure  13.  In  the 
schema,  applicable  object  classes  participate  in  one-to-one  relationdiips  with  SINGLE 
PULSE  PROCESSING  objects  or  MULTIPLE  PULSE  PROCESSING  objects. 
However,  both  the  SINGLE  PULSE  PROCESSING  and  MULTIPLE  PULSE 
PROCESSING  classes  exist  solely  to  provide  the  capability  to  access  receiver-signal 
information  from  a  single  pulse/multiple  pulse  processing  bias.  Their  primary  purpose  is 
navigational.  These  two  classes  are  descr^tive  of  receiver  data  in  name  alone. 

Multiple  one-to-one  relationships  originate  from  the  SIGNAL  PROCESSOR 
SECTION  class.  The  other  partic^ating  classes  -  SPECIAL  CAPABILITIES, 
DOPPLER  PROCESSING,  INTEGRATION,  MOVING  TGT  INDICATION,  TGT 
TRACKING,  and  THRESHOLDEVG/TGT  DETECTION  -  encapsulate  data  that 
describe  the  functionality  of  a  receiver’s  agnal  processor  section.  The  choice  to  use 
reference  relationsh^s  instead  of  aggregation  relationships  is  based  on  the  conposition  of 
the  EWIRDB  data.  In  general,  as  signal  procesang  is  addressed  with  an  increasing  level 
of  detail  with  respect  to  fimctionality,  hardware  differences  among  receivers  tends  to 
become  more  pronoimced.  In  other  words,  as  the  granularity  of  data  increases,  receivers 
may  still  be  described  in  terms  of  common  functionality,  but  tend  to  be  less  alike  in 
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hardware.  Functionality  is  therefore  less  prone  to  be  cast  in  the  hght  of  hardware  as  the 
data  become  more  detailed.  The  other  classes  are  not  so  much  parts  of  SIGNAL 
PROCESSOR  SECTION  as  they  are  descriptors  of  the  types  of  actions  performed  in 
that  section.  Aggregation  semantics  become  less  applicable;  reference  relationsh4)S  better 
model  the  nature  of  this  interaction. 

4.  WARM  Data 

The  design  of  Figure  15  echoes  previously  introduced  elements  of  the  conceptual 
schema.  For  example,  the  class  POWER  ECCM  partic4)ates  in  a  one-to-many 
relation  ship  with  TRANSMISSION  POWER  from  Figure  12.  As  will  be  found  in  the 
logical  deagn,  this  relationsh^  indicates  that  a  WARM  mode  affecting  signal  power,  or  an 
object  of  the  class  POWER  ECCM,  is  essentially  a  new  mstantiation  of  the  class 
TRANSMISSION  POWER.  WARM  modes  that  are  not  variations  of  existing  data 
classes  fall  within  the  class  OPERATIONAL  ECCM. 

The  inheritance  hierarchy  in  Figure  15  is  digoint;  any  given  object  of  the  WARM 
class  is  a  member  of  only  one  ^eciahzation  class.  However,  an  emitter  may  exhibit 
multiple  WARM  modes,  as  modeled  in  the  one-to-many  relationships  between  the  classes 
KILTING  EMITTER  and  WARM,  S&TI  EMITTER  and  WARM,  and  USNCSDB 
EMITTER  and  WARM. 

This  approach  to  the  modeling  of  WARM  data  does  away  with  the  need  to 
account  for  the  Reserve  Mode  entry  found  in  SOS  records  (Figure  5). 


D.  THE  PARAMETRIC  DATA  CLASS 

As  discussed  in  section  HI. A  l.b,  conq)lex  attributes  support  objects  as  attribute 
values.  Therefore,  in  the  case  of  complex  attributes,  the  “type”  ofa  given  attribute  is 
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equivalent  to  the  particular  object  class  from  which  that  object  value  was  instantiated. 
Further,  conoplex  attributes  may  reflect  an  arbitrarily  deq)  or  recursive  nesting  of  objects. 

All  con:q)lex  attributes  in  the  object-oriented  design  of  EWIRDB,  regardless  of  the 
depth  of  nesting,  ultimately  lead  to  objects  of  the  class  PARAMETRIC  DATA,  the  focus 
of  this  section.  The  PARAMETRIC  DATA  class  itself  ejdiibits  a  nesting  of  objects  that 
incorporates  the  semantically-usefijl  data  elements  of  the  SOS,  S04,  and  SOS  records. 

The  PARAMETRIC  DATA  class  and  the  data  encapsulated  therein  is  depicted  in 
Figure  16.  TEXTUAL  DATA  and  NUMERIC  DATA  are  q)ecializations  of 
PARAMETRIC  DATA,  and  intuitively  indicate  whether  the  parametric  data  entry  for  a 
given  attribute  is  text-based  or  numerical.  Numerical  parametric  data  are  either  single¬ 
valued  or  range-valued  as  e7q)ressed  in  the  specialization  classes  SPECIFIC  VALUE  and 
VALUE  RANGE. 

In  the  EWIRDB,  comments  are  used  to  further  characterize  parametric  data 
values.  PARAMETRIC  DATA  thus  participates  in  one-to-one  relationship  with  the 
class  DATA  COMMENT.  The  participation  of  DATA  COMMENT  in  the  relationship 
is  total;  a  parametric  data  entry  must  first  exist  before  a  corresponding  comment  can  be 
made,  but  not  all  parametric  data  entries  must  be  commented.  If  a  parameter  is  assessed, 
then  a  related  comment  must  also  include  the  comment  classification.  This  is  depicted  in 
the  specialization  class  ASSESSED  DATA  COMMENT.  Comment  data  and  the 
inheritance  hierarchy  directly  subordinate  to  the  PARAMETRIC  DATA  class  are 
enclosed  within  the  dotted  line  in  Figure  16.  Together  they  constitute  the  core  of 
EWIRDB  parametric  data. 

On  the  global  scale,  each  emitter  is  linked  to  emitter-specific  administrative  data; 
on  a  smaller  scale,  each  class  attribute  is  associated  with  the  attribute- specific 
administrative  data  associated  with  the  S03,  S04,  and  SOS  records.  The  attribute- specific 
administrative  data  identifies  data  references  and  highlights  iixportant  descriptive 
information.  As  indicated  in  Figure  15,  the  format  of  this  data  is  source-dependent. 
ORIGINAL  SOURCE  DOCUMENTATION  includes  those  attributes  conamon  to  both 
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attributes: 


accuracy 

acci^^^ 

intelligence  source 
preferential  rating 

Figure  16.  The  Conceptual  Schema:  Parametric  Data 


attributes: 


confidence  level 

_ classification 

releasibility 
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formats,  report  classification  and  report  releasability.  Formatting  distinctions  are  made 
within  the  specialization  classes  ASSESSED  REFERENCE  and  OBSERVED 
REFERENCE.  Attribute  values  are  further  characterized  in  the  DATA  DESCRIPTION 
class  by  date  of  last  update.  (  The  method  parametric  update  date  in  the  class 
EWIRDB  ADMINISTRATIVE  DATA  (Figure  9)  accesses  date  of  last  update 
information  throu^out  the  database  and  returns  the  most  recent  value  for  a  given 
emitter.)  Source-dq)endent  characteristics  that  generally  describe  the  soundness  and 
accuracy  of  a  given  attribute  value  are  addressed  in  the  specialization  classes  ASSESSED 
DATA  and  OBSERVED  DATA. 

Two  methods  are  specified  in  the  PARAMETRIC  DATA  class:  return  all  data 
and  return  parametric  data.  For  a  given  attribute,  return  all  data  will  reply  with  all 
available  data  -  the  actual  parametric  data  as  well  as  the  associated  administrative  data, 
return  parametric  data  will  yield  only  the  data  enclosed  within  the  dotted  line  m  Figure 
15  for  a  given  attribute.  One  attribute  is  specified  as  well,  suffix  code,  a  label  for  the 
given  attribute  as  it  appears  in  the  sufiBx  table. 

Thus,  all  usefiil  data  items  from  the  SOS,  S04,  and  SOS  records,  with  the  exception 
of  sufiObc  table  information,  are  nested  within  the  PARAMETRIC  DATA  class  of  Figure 
15.  Object-orientation  eliminates  the  need  for  many  previously  maintained  data  items 
listed  in  Figure  5.  Tree  Number,  wfrich  provides  indexing  into  the  parametric  tree  is  no 
longer  required.  Linking-type  entries  related  to  the  format  of  the  output  file  -  Reference 
Number  (SOS),  Comment  Number  (SOS),  Reference  Number  (S04),  Reference  Line 
Number,  Comment  Number  (SOS),  and  Comment  Line  Number  -  are  eliminated.  Finally, 
the  &itsy  Measurement  Name  (SOS)  is  replaced  by  the  attribute  name  itself 

At  this  point,  aU  meaningfiil  data  entries  of  the  TERF  have  been  integrated  into 
one  conq>rehensive,  encapsulated  model. 
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E.  SUFFIX  CODING  AND  THE  SUFFIX  TABLE 

EWIRDB  suffix-coded  data  and  the  suffix  table  representation  of  data  conq)rise 
the  most  difficult  modeling  task  in  the  conceptual  design.  Suffix  coding  is  incorporated 
within  the  EWIRDB  to  describe  the  vast  array  of  mode  combinations  an  emitter  may 
e^diibit.  In  effect,  suffbc-coding  links  together  the  parametric  values  that  characterize 
known  or  suspected  emitter  usage.  A  particular  combination  of  parametric  values  defines 
a  given  mode;  suffbc  coding  and  suffix  table  thus  provide  the  means  for  establishing 
relationsh^s  between  parametric  values  throughout  the  database.  (A  con^rehensive 
review  of  sufiBx  coding  and  the  suffix  table  is  provided  in  [1].) 

Herein  lies  the  complexity  in  modeling  modal  relationships.  Parametric  values  are 
synonymous  with  attribute  values.  The  attributes  whose  values  describe  a  given  mode  are 
likely  interspersed  throu^out  the  many  classes  in  the  schema.  The  relationships  defined 
by  suffix  coding  and  the  sufiSx  table  therefore  describe  associations  between  attributes  — 
not  classes.  An  additional  conoplication  is  the  possibility  of  multiple  values  (multiple 
instantiations  of  the  object  that  contains  the  attribute)  each  for  a  given  attribute.  Modeling 
modal  (attribute)  relationsh^s  is  difficult  because  neither  the  OODM,  nor  any  other  data 
model,  e?qp]icitly  supports  such  a  capability.  From  a  modeling  perfective,  the  problem  of 
representing  modal  relationshf  s  such  as  those  found  in  the  suffk  table  reduces  to  problem 
of  representing  attribute-to-attribute  relationships  and  attiibute-to-attribute  combinations. 

Upgrading  each  attribute  to  a  class  is  an  ineffective  solution.  Related  attributes  are 
grouped  into  classes  for  the  purpose  of  collectively  describing  the  characteristics  of  a 
particular  set  of  objects.  The  transformation  of  attribute  to  class  obscures  these  semantics; 
each  attribute  instead  becomes  a  reference  within  a  given  class.  Moreover,  the  problem  of 
modeling  combinations  remains  unsolved.  There  exists  no  “built-in”  OODM  mechanism 
for  the  purpose  of  defining  combinations  of  objects,  not  to  mention  attributes,  throughout 
a  schema. 

The  process  of  defining  modal  combinations,  regardless  of  the  modeling  tool  used, 
is  formidable  in  the  realization  that  an  emitter  could  likely  exhibit  hrmdreds  of  thousands 
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of  inodes.  Object-orientation  does  not  appear  to  sinqilify  this  task.  Despite  its 
dependence  on  an  artificial  labeling  system  and  a  non-intuitive  table  representation,  sufSx 
coding  has  provea  to  be  effective  in  this  combination-oriaited  modeling.  Moreover,  it 
helps  to  link  signal  signatures  to  emitters.  At  present,  I  am  unable  to  offer  an  easier  or 
more  viable  modeling  ahemative.  The  current  methodology  is  therefore  incorporated  into 
the  object-oriented  conceptual  design. 

The  conceptual  schema  includes  a  sufBx  code  entry  for  every  attribute  throughout 
the  schema;  a  suffix  code  entry  can  be  made  fijr  every  attribute  in  each  instantiation  of  the 
object  to  which  the  attribute  belongs.  This  provides  for  the  same  modeling  flexibility  as 
exists  in  the  current  model:  the  binding  together  of  related  parameters,  the  labeling  of 
multiple  values  for  a  given  attribute,  and  the  inclusion  of  sufBx-coded  data  within  the 
SUFFIX  TABLE  class  of  objects  (Figures  9,  10,  11)  to  develop  modal  combinations. 
SUFFIX  TABLE  objects  would  also  contain  a  method,  expand  table  (not  shown),  to 
return  aU  combinations  represented  in  the  suffix-coded  data  table. 

In  the  object-oriented  design,  the  use  of  the  special  suffix  codes  is  no  longer  useftil. 
The  semantics  of  the  special  suffix  code,  ++,  used  to  indicate  that  a  particular  parametric 
value  is  present  in  all  modes,  may  be  addressed  via  comment  in  the  DATA  COMMENT 
class  (Figure  15).  The  special  code,  //,  applies  specifically  to  the  parametric  tree  structure 
and  indicates  that  a  given  value  pertains  to  all  modes  described  within  the  subtree  rooted 
at  the  branch  containing  the  special  code.  Such  semantics  are  in^hcit  in  inheritance  and 
aggregation  hierarchies,  and  may  be  explicitly  addressed  via  comment. 

This  con5)letes  the  conceptual  design  phase.  The  next  stage  in  the  overall  design 
process  is  the  logical  design,  addressed  in  Chapter  V. 
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V.  A  LOGICAL  OBJECT-ORIENTED  EWIRDB 


The  O-ODDL  native  to  the  M^DBS  in  the  NFS  Laboratory  for  Database  Systems 
Research  provides  the  structure  of  the  logical  design  presented  in  this  chapter.  The  O- 
ODDL,  designed  and  q)ecified  in  [12],  thus  provides  the  means  to  convert  the  concq)tual 
database  as  proposed  in  Chapter  IV  into  an  M^DBS-conopatible  representation. 

Still  in  its  first  phase  of  development,  the  object-oriented  interface  to  the  M^DBS 
is  fimctional  but  does  not  yet  support  all  aspects  of  the  object-oriented  paradigm.  To 
date,  methods  and  the  aggregation  abstraction  are  not  in:q)lementable  on  the  M^DBS. 
Therefore,  in  the  logical  design,  aggregation  will  be  represented  via  relationships,  and 
methods  will  not  be  addressed. 

It  is  not  necessary  to  address  all  aspects  of  the  conceptual  schema  in  the  logical 
design  to  demonstrate  the  operation  of  the  M^DBS  object-oriented  interfece  in  handling 
EWIRDB  data.  To  this  end,  I  address  a  representative  portion  of  the  conceptual  schema 
in  developing  the  logical  design.  The  subsequent  inq)lementation  of  the  logical  schema  on 
the  M^DBS  is  a  continuation  of  the  work  in  this  thesis,  and  is  addressed  in  [13, 
unpublished].  The  final  result  of  this  combined  effort  will  be  an  on-line  object-oriented 
EWIRDB  with  which  to  demonstrate  both  the  utility  of  the  new  M^DBS  object-oriented 
interfece,  and  the  usefulness  of  the  new  object-oriented  EWIRDB  design. 

The  O-ODDL  logical  design  constructs  are  reproduced  in  Figures  17  through  20. 
Refer  to  [12]  for  a  conq)rehensrve  discussion  of  the  O-ODDL  specification. 

In  Figure  17,  “attribute  type”  refers  to  the  traditional  notion  of  attribute  domain. 
As  described  earlier  in  sections  HI.  A  l.a  and  b,  the  domain  or  type  of  an  attribute  may  be 
simple,  characterized  by  literal  attribute  values,  or  the  type  may  be  conqjlex,  characterized 
by  object  attribute  values.  Complex  attributes  can  therefore  erfiibit  an  arbitrarily  deep 
nesting  of  objects.  Whereas  a  smq)le  attribute  may  be  of  type  “character”  or  “integer”,  the 
type  of  a  corqplex  (or  reference)  attribute  is  a  class.  The  class  defines  the  legal  attribute 
values  (object  values)  for  the  given  attribute. 


65 


Figures  18  and  19  contain  the  ^ecdfications  for  the  inheritance  and  covering 
abstractions.  In  Figure  20,  one-to-many  and  many-to-many  relationships  are  addressed. 
One-to-many  (1;N)  relationsh^s  between  object  classes  are  represented  via  the  set_of 
construct.  set_of  appears  within  the  class  on  the  “1”  side  of  the  relationsh^;  an  attribute 
that  references  the  class  on  the  “1”  side  of  the  relationship  appears  within  the  class  on  the 
“N”  side  of  the  relationship.  Many-to-many  (N:M)  relationships  are  represented  with  the 
set_of  (N  side)  and  inverse_of  (M  side)  constructs.  One-to-one  (1:1)  relationships  are 
represented  directly  through  use  of  reference  attributes.  The  classes  in  the  1: 1  relationship 
each  contain  an  attribute  whose  type  is  that  of  the  class  to  which  it  is  associated  via  the 
1:1  relation^p. 


Oass  Class  name  { 

attribute_typei  attribute_namei; 
attributejypea  attribute  namea; 

attributejypen  attribute  namen 

}; 

Figure  17.  The  O-ODDL  Oass  Specification 


Oass  Class jiame  Xl :  inherit  Class_name_X{ 
attribute  typei  attribute_namei; 
attribute_type2  attribute_name2; 


attribute  typen  attribute_namen 

}; 


Figure  18.  The  O-ODDL  Inheritance  Specification 
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Oass  Class_name_Xl :  cover  Class_name_X{ 
attribute_typei  attribute  namei; 
attribute_type2  attribute  namez. 


attribute_type„  attribute_name„ 

}; 


Figgie  19.  The  O-ODDL  Cover  Specification 


set_of  Classjiame  attribute_nanie; 

inverse_of  C/as5_«awe.attribute_name  attiibute_name; 


Figure  20.  The  O-ODDL  Set_of  and  Inverse_of  Specifications 

The  logical  design  incorporates  the  O-ODDL  constructs  as  outlined  in  Figures  21 
throu^  29.  Because  all  con5)lex  attributes  in  the  object-oriented  design  of  EWIRDB, 
ultimately  lead  to  objects  of  type  PARAMETRIC  DATA  (section  IV.D),  the  logical 
design  begins  with  the  O-ODDL  representation  of  PARAMETRIC  DATA  in  Figure  21. 
The  design  then  proceeds  with  the  classes  EMITTER  (Figure  22),  KILTING 
EMITTER  and  KILTING  ADMINISTRATIVE  DATA  (Figure  23),  ANTENNA 
(Figure  24),  SIGNAL  (Figure  25),  RECEIVER  (Figure  26),  WARM  (Figure  27), 
SUFFIX  TABLE  (Figure  28)  and  S&TI  EMITTER  and  S&TI  ADMENISTRATTVE 
DATA  (Figure  29). 
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class  Parametric  J^ata{ 
char* 

DataJ3omment 

DataDescript 

set  of  Orig  Src  Doc, 

}; 

sufl5x_code; 

comments; 

description; 

references; 

class  Textual  Data :  inherit  ParametricJData  { 

char* 

}; 

text; 

citkss  Numeric  Data  :  inherit  Parametric  Data  { 

char* 

}; 

units; 

class  Specific JValue  :  inherit  Numeric_Data{ 

char* 

}; 

value; 

class  Value_Range  :  inherit  Numeric_Data{ 

char* 

uppervahie; 

char* 

}; 

lowervalue; 

class  DataJZomment  { 

char* 

comment_text; 

Parametric  Data 

}; 

parametricdata; 

class  Assess  Comment :  inherit  Data_Comment  { 

char* 

com  classif; 

}; 

F^ure  21.  The  Logical  Design:  DDL  Implementation  of  the 

PAR4METRIC  DATA  Class  (cont’d  into  next  page) 
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class  Data_pescrip  { 

char*  lastupdate; 

Parametric  Data  para  data; 

}; 

class  Assessed  Data : 

inherit  Data_Descrip{ 

char* 

confidence_level; 

char* 

classification; 

char* 

}; 

releasability; 

class  ObservedJData : 

:  inherit  Data_Descrip{ 

char* 

meas  accuracy; 

char* 

measaccunits; 

char* 

intel_source; 

int 

}; 

preferrating; 

class  Orig_Src_Doc  { 

char* 

rptclassif; 

char* 

iptrelease; 

inverse  of  Parametric  Z)ato.refereaces  p  data; 

}; 

class  Assessed_Ref :  inherit  Orig_Src_Doc  { 

char* 

}; 

referencetext; 

class  ObservedJRef :  inherit  Orig_Src_Doc  { 

char* 

document  number; 

char* 

documenttitle; 

char* 

reportdate; 

char* 

producer; 

char* 

}; 

reportclassification; 

Figure  21.  (cont’d)  The  Logical  Design:  DDL  Implementation  of 
the  PARAMETRIC  DATA  Oass 
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class  Emitter { 

char* 

elnot; 

char* 

color; 

Kilting  Emitter 

kilting  data; 

S&TI  Emitter 

s_and_ti_(iata; 

}; 

Figure  22.  The  Logical  Design:  DDL  Implementation  of  the 
EMITTER  Class 


class  Kilting  Emitter  { 

char* 

technicaldate; 

KiltingAdmin 

kadmindata; 

set_of  Antenna 

antennadata; 

set_of  Signal 

signaldata; 

set_of  Receiver 

receiver_data; 

set  of  WARM 

warresmodes; 

Suffix_Table 

modes; 

ParametricJData 

weapon_system; 

Parametric  Data 

function; 

Parametric JData 

platform; 

Emitter 

}; 

generaldata; 

class  Kilting_Admin{ 

char* 

nsadate; 

char* 

saecode; 

char* 

datesigchange; 

char* 

kclassification; 

char* 

}; 

kreleasabihty; 

Figure  23.  The  Logical  Design:  DDL  Implementation  of  the 
KILTING  EMTITER  and  KILTING 
ADMINISTRATIVE  DATA  Classes 
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class  Antenna{ 

Parametric J^ata 
Parametric _pata 
ParametricData 
ParametricData 
Polarization 

Radiation J^attem 

Kilting  Emitter 

}; 

antennatype; 

antenna_fimction; 

horizontaldimension; 

verticaldimension; 

ant_polarization; 

antradchar; 

kilt_eniitter; 

class  Polarization^ 

Cross  ^Polarization 

cross_pol_char; 

Antenna 

}; 

antenna; 

class  Cross _Polarization{ 

Parametric J^ata 

patt_pk_ofifeet; 

Parametric _Data 

pattjpkjresp; 

Polarization 

polarization;  }; 

class  Linear  JPolarization  :  inherit  Polarization{ 

Parametric _pata 

}; 

niajor_axis_tilt_angle; 

class  Circ_or_Ellipt  JPolarization : 

inherit  Polarization^ 

Parametric JData 

sense; 

Parametric  Data 

axial_ratio; 

}; 

Figure  24.  The  Logical  Design:  DDL  Implementation  of  the 
ANTENNA  Class  (cont’d  into  next  page) 
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class  Radiation_Pattem{ 
Parametric JData 

Antenna 

}; 

antenaa_gain; 

ant; 

class  Directional  Ant :  inherit  Radiation_Pattem{ 

Parametric  Data 

beaniwidth_az; 

Parametric  Data 

beamwidthel; 

Parametric  Data 

first  sidelobe  M  az; 

Parametric _Pata 

first_sidelobe_M_el; 

set_of  Scan 

scanningchar; 

set  of  Track 

trackingchar; 

}; 

class  Omnidirectional :  inherit  Radiation_Pattem{ 

Parametric _pata 

elevation  coverage  angle; 

}; 

class  Scan{ 

Parametric  Data 

san5)le_avg_time; 

Parametric  Data 

SNR._threshold; 

Parametric  Data 

planeo^scan; 

Directional  Ant 

}; 

dirantenna; 

class  Mechanical ^can  :  inherit  Scan{ 

Parametric _pata 

typechange; 

Parametric  Data 

scan  function; 

}; 

class  Circular :  inherit  Mechanical_Scan{ 

Parametric _pata  cperiodjimits; 

}; 


Figure  24.  (cont’d)  The  Logical  Design:  DDL  Implementation  of 
the  ANTENNA  Qass  (cont’d  into  next  page) 
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class  Sector :  iDhtrit  Mechariical_Scan{ 

Parametric  Data 

sectortype; 

Parametric  Data 

speriodjimits; 

Parametric JData 

sector  width  az; 

Parametric  Data 

sector  width  el; 

}; 

class  Track{ 

Parametric  Data 

planeo^scan; 

Directional  Ant 

}; 

direct_ant; 

class  MechJTracking :  inherit  Track{ 
Parametric _pata 
autotrackjmaxrateaz; 
Parametric JData 
autotrackmaxrateel; 


F^ure  24.  (cont’d)  The  Logical  Design:  DDL  Implementation  of 
the  ANTENNA  Class 
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class  Signal  { 

TransJPower 

Kilting  Emitter 

}; 

signal_pwr; 

k_emitter; 

class  Trans_Pawer{ 

Parametric  Data 

line  loss  on  tx; 

Parametric J^ata 

pk_pvvr  efl^rad; 

Parametric _pata 

pkjjwrattrans; 

Signal 

}; 

signal; 

class  Constant  Power :  inherit  Transmission_Power{ 

Parametric  Data 

}; 

timetoswitch; 

class  NotConstant_Power  :  inherit  Transmission_Pawer{ 

Parametric  Data 

maxjrateo^change; 

}; 

class  Pulsed_RF :  inherit  Signal { 

RF  Line  Structure 

coherence; 

Pulse  Duration 

pnlselength; 

PRI/PGRI 

piilse ^groups; 

}; 

class  RF_Line_Structure{ 

Parametric_Data 

3_db_spec_width; 

Parametric JData 

transtype; 

Pulsed  RF 

}; 

ilQ)iilse; 

Figure  25.  The  Logical  Design:  DDL  Implementation  of  the 
SIGNAL  Qass  (cont’d  into  next  page) 
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class  Pulse _Duration{ 

Parametric _pata 
Parametric  Data 

Pulsed  RF 

}; 

pulsedurlim; 

pd_most_prob; 

pulse; 

fAas,%PD_Modulated :  uiheTit  Pulse  Duration{ 

Parametric  Data 

deyjinnts; 

Parametric  Data 

}; 

modulation_rate; 

class  RF  Constant :  inherit  Pulsed  RF{ 

Parametric _pata 

rfjimits; 

Parametric  Data 

}; 

most_prob_if; 

class  RF  Not  Constant :  inherit  Pulsed  RF{ 

}; 

tAASsModon_Pulse :  vBiheritRFNotconstant{ 

Parametric  Data 

}; 

ifjnodchange; 

class  PMOP :  mhxxitMod  on  Pulse{ 

Parametric  Data 

rf  limits; 

Parametric  Data 

}; 

phase_shift; 

class  FMOP :  iBi\icritMod_on_Pulse{ 

Parametric _pata 

jEbiop  rf  limits; 

Parametric J^ata 

fi:eq_excursion; 

}; 


Figure  25.  (cont’d)  The  Logical  Design:  DDL  Implementation  of 
the  SIGNAL  Oass  (cont’d  into  next  page) 
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class  Pulsed  Agility :  inherit  RF J^ot_constant{ 

Parametric _Data 

agil_fiuic_coir; 

Parametric  Data 

}; 

mod_waveform; 

class  Cont_Agility :  inherit  Pulsed_Agility{ 

Parametric  Data 

}; 

r^limits; 

Q\ass  Disc  Agility :  \sihtritPulsed_Agility{ 

Parametric  Data 

rfjimits; 

Parametric  Data 

no_disc_steps; 

}; 

class  PRI{ 

Parametric  Data 

meas  bandwidth; 

Pulsed  RF 

rf; 

}; 

class  Not_Comt_PRI :  inherit  PRI{ 

Parametric _pata 

modulationtype; 

Intvl  Sked 

}; 

mterval_cntrl; 

class  Intvl_Sked{ 

Parametric JData 

duty_cycle; 

set  o{  Recurrent  Intvl 

intervals; 

); 

Figure  25.  (cont’d)  The  Logical  Des^n:  DDL  Implementation  of 
the  SIGNAL  Oass 
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class  Recurrent_Intvl{ 
Parametric J)ata 
Intvl  Sked 

}; 

nbr_dsca’ete_int; 

sked_control; 

class  Recur_Intvl_Seq :  cover 
Parametric  Data 

}; 

Recurrent J.ntvl{ 

sequencel; 

- - - - - 1 

Figure  25.  (cont’d)  The  Logical  Design:  DDL  Implementation  of 
the  SIGNAL  Gldss 

class  Receiver  { 

Parametric_Data 

SigProcSect 

A_D_Conv_Sect 

S&TI  Emitter 

}; 

receivertype; 
sig  processor: 
a_d_section; 
s_enntter; 

class  Sig  Proc  Sect  { 

Doppler  processing 
Receiver 

}; 

dopproc; 

receiver; 

class  Doppler  Processing  { 
ParametricData 
Parametric _Data 

Sig  Proc  Sect 

}; 

cohjproc_intrvl; 

pulses_in_cpi; 

processor 

Figure  26.  The  Logical  Design:  DDL  Implementation  of  the 
RECEIVER  Qass  (cont’d  into  next  page) 
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class  Multiple _Pulse_Processmg  { 

Doppler  processing  n9_dopjproc, 

>; 


class  A_D_Conv_Sect  { 
Parametric  Data 
Parametric _pata 
Receiver 

}; 


class  Single _Pulse_Processing{ 
A_D_Convr_Sect 
Pulse  Compression 


class  Pulse_Compression{ 

Parametric_Data  t^e_of_codmg; 

Parametric_Data  time_baQd_prod, 

Sig_Pulse_Proc  singlejulse; 


Figure  26.  The  Logical  Design:  DDL  Implementation  of  the 
RECEIVER  Class 


a_d_coiiverter; 

piilse_corapress; 


a_saii5)le_period; 

convtrigmeth; 

rcvr; 
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class  WARM{ 

char*  prob_code; 

Kilting_Emitter  kilt_eimt; 

}; 


class  Power _ECCM :  inherit  WARM{ 
set_of  Tram  Pawer 

res_pwr_mode; 

}; 

class  Polar  ECCM :  inherit  WARM{ 
set  of  Polarization 

}; 

res_polar_inode; 

class  Ant_Scan_ECCM :  inherit  WARM{ 
set  of  Scan 

}; 

res_scan._mode; 

class  Sig_Shape_ECCM :  inherit  WARM{ 
set  of  Pulse  Duration 

}; 

resjpd_niode; 

class  RF_ECCM\  inherit  WARM{ 
set  of  Puked  RF 

}; 

resjtfmode; 

Figure  27.  The  Logical  Des^n:  DDL  Implementatioii  of  the 
WARM  Class 
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class  Suffix_Table{ 

char* 

}; 

modematrix; 

F^ure  28.  The  Logical  Design:  DDL  Implementation  of  the 
SUFFIX  TABLE  Gass 


class  S&TJ_Emitter{ 

S&TI  Admin 

kadmindata; 

set  of  Antenna 

aiiteima_data; 

set_of  Signal 

signal_data; 

set_of  Receiver 

receiver_data; 

set  of  WARM 

warresmodes; 

SuffixTable 

modes; 

Parametric  Data 

weaponsystem; 

Parametric _pata 

function; 

Parametric _Data 

platform; 

Emitter 

}; 

general_data; 

class  S&TI_Admin  { 

char* 

s&ti_code; 

char* 

mult_src_review; 

char* 

sclassification; 

char* 

}; 

sreleasabihty; 

Figure  29.  The  Logical  Design:  DDL  Implementation  of  the 
S&TI  EMITTER  and  S&TI  ADMINISTRATIVE 
DATA  Classes 
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The  effect  of  the  object-oriented  logical  design  is  profound.  Now,  all  available 
data  for  a  given  emitter,  both  technical  and  administrative,  is  contained  within  an  object  of 
the  class  EMITTER.  This  effect  is  achieved  via  the  nesting  of  objects  within  the 
ffamework  of  relationships,  inheritances,  and  a  covering. 

EMITTER  contains  complex  (reference)  attributes  (object  values)  of  type 
PARAMETRIC  DATA,  and  also  contains  references  to  source-specific  emitter  data 
objects  of  type  KILTING  EMITTER  and  S&TI  EMITTER.  KILTING  EMITTER 
and  S&TI  EMITTER  objects  likewise  contain  attributes  of  type  PARAMETRIC 
DATA,  and  attributes  that  reference  analogous  administrative  data  objects.  These 
administrative  data  objects  contain  simple-valued,  source- specific  attributes  corre^onding 
to  SOO,  SOI,  and  S02  record  data.  The  KILTING  EMITTER  and  S&TT  EMTITER 
objects  additionally  encapsulate  antenna  data,  signal  data,  receiver  data,  WARM  data,  and 
suffix  table  objects.  (Suffix  table  objects  correspond  to  SOS  record  data).  The  attributes 
within  each  of  these  objects,  in  turn,  are  either  of  type  PARAMETRIC  DATA,  or  e^dubit 
a  nesting  of  objects  that  ultimately  lead  to  attributes  of  type  PARAMETRIC  DATA. 

Finally,  attributes  of  type  PARAMETRIC  DATA  exhibit  a  nesting  of  objects  that 
leads  to  single  parametric  values  and  ample  parametric-vahie-related  admunistrative  data. 
All  such  information  corresponds  to  S03  record  data. 

The  overall  result  is  a  cohesive,  encapsulated,  and  conprehensive  logical  schema 
of  EWIRDB  data. 
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VL  CONCLUSION 


The  EWIRDB  is  a  vitally  in^ortant  instrument  of  EW  and  EW  research  and 
development,  containing  up-to-date  and  mission-critical  performance  data  on  the  EW 
systems  of  fiiendly  and  hostile  forces.  Its  utilization  in  the  areas  of  battle  planning  and 
EW  research  he^s  to  shape  the  outcome  of  war.  The  usefulness  of  the  EWIRDB, 
however,  is  hampered  by  its  cumbersome  data  model,  the  basis  of  vshich  is  an  inherently 
arbitrary  parametric  tree  structure.  The  inconsistencies  that  exist  among  the  data  as 
modeled  in  the  parametric  tree  and  the  data  as  addressed  in  the  record-based  output  jSle 
further  obscure  the  intended  semantics.  The  overall  data  representation  is  non-intuitive, 
disjoint,  and  dMcuh  to  conq)rehend.  The  burden  of  data  interpretation  is  transferred  to 
the  user,  and  the  user  must  deal  at  length  with  formatting  and  coding  issues. 

In  this  thesis,  I  have  proposed  an  alternative  and  improved  representation  of 
EWIRDB  data.  The  design  effort  was  centered  on  the  development  of  a  legitimate 
conceptual  design,  followed  by  development  of  a  logical  design  suitable  for 
implementation  on  the  M^DBS  in  the  NPS  Laboratory  for  Database  Systems  Research. 
The  conceptual  and  logical  designs  are  the  first  two  phases  in  the  overall  database  design 
and  inplementation  process. 

The  conceptual  design  has  yielded  a  conceptual  schema  that  captured  the  nature  of 
a  rpresentative  portion  of  EWIRDB  data  in  a  way  that  closely  paralleled  the  user’s 
percption  of  the  data.  The  basis  of  the  conceptual  design  was  the  OODM,  a  powerfid 
modeling  tool  that  enables  the  dedgner  to  reduce  the  semantic  mismatch  between  real- 
world  entities  and  their  database  representations.  The  OODM  incorporates  the  concpts 
of  objects,  encapsulation,  object  classes,  instantiation  and  classification,  generalization  and 
specialization,  aggregation,  and  covering  to  achieve  this  end.  The  object-oriented 
conceptual  design  has  captured  both  the  technical  and  administrative  semantics  of  EW 
data  to  a  degree  not  previously  achievable.  This  was  the  realization  of  the  primary 
objective  of  the  thesis. 
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In  the  logical  design,  I  have  mapped  the  object-oriented  concq)tual  schema  to  the 
object-oriented  data  model  of  the  M^DBS.  The  mapping  is  accon^lished  via  the  O- 
ODDL  native  to  the  M^DBS.  The  resulting  O-ODDL  statements  constitute  the  logical 
schema;  they  are  an  M^DBS-readable  specification  of  the  conceptual  schema.  The  O- 
ODDL  provided  for  an  arbitrarily  deep  nesting  of  objects  within  a  framework  of 
relationships,  inheritance,  and  covering.  The  semantics  of  the  data  have  been  preserved  in 
the  mapping;  w^ien  in^lemented  on  the  M^DBS,  these  semantics  will  be  supported  by  the 
M^DBS.  This  is  a  huge  benefit  -  the  database  user  is  thereafter  relieved  of  the 
rgspnnsibilify  of  data  translation  and  interpretation.  Although  it  does  not  yet  support 
methods  or  aggregation,  the  O-ODDL  provides  for  an  intuitive,  cohesive,  and  nested 
implementation  of  technical  and  administrative  data.  Therefore,  the  inplementation  is 
much  improved  over  the  coirplex  record-based  format  that  currently  exists. 

The  logical  design  portion  of  the  this  work  provides  input  for  the  subsequent  use 
atiH  evaluation  of  the  object-oriented  interface  to  the  M^DBS,  and  in  this  regard  satisfies 
the  secondary  objective  of  the  thesis.  la  due  course,  the  logical  schema  will  be 
inplemented  on  the  M^DBS  to  produce  an  on-line  object-oriented  EWIRDB  with  \riiich 
to  demonstrate  both  the  utility  of  the  new  M^DBS  object-oriented  interfece  and  the 
usefiilness  of  the  new  object-oriented  EWIRDB  design. 

Object-orientation  did  not  appear  to  simplify  the  formidable  task  of  modeling 
emitter  mode  combinations,  currentfy  represented  through  use  of  suffix  codes  and  suffix 
tables.  For  this  reason,  I  retained  the  suffix  code-suflSx  table  system  in  the  designs 
presented  in  this  thesis.  Consequently,  the  use  of  this  system  comphcates  the 
implementation  of  the  database.  In  the  object-oriented  approach,  however,  a  reliance  on 
external  software  to  inteifiice  with  suffix  tables  is  unnecessary.  Such  manipulation  may  be 
achieved  internal  to  the  DBMS  via  methods.  A  true  modeling  solution  may  depend  on  the 
development  of  a  data  model  that  provides  the  flexibility  to  address  attribute-to-attribute 
relationsh^s  and  combinations. 
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Overall,  the  conceptual  and  logical  designs  developed  in  this  thesis  support  and 
confirm  the  object-oriented  approach  as  a  viable  solution  to  the  modeling  inadequacies  of 
the  present  EWIRDB. 


85 


1 


1 


86 


LIST  OF  REFERENCES 


[1]  National  Air  Intelligence  Center,  Electronic  Warfare  Integrated  Reprogramming 
Database  (EWIRDB)  Guide,  Volume  1,  April  1994. 

[2]  Elmasri,  R.,  and  Navathe,  S.,  Fundamentah  of  Database  Systems,  The 
Benjamin/Cummings  Publidiing  Conq>any,  Inc.,  1994. 

[3]  Kim,  W.,  “Object-Oriented  Databases;  Definition  and  Research  Directions,”  IEEE 
Transactions  on  Knowledge  and  Data  Engineering,  vol.  2,  no.  3,  September  1990. 

[4]  CatteU,  R,  Object  Data  Management  -  Object-Oriented  and  Extended  Relational 
Database  Systems,  Addison-Wesley  Publishiug  Con5)any,  Inc.,  1994. 

[5]  Bertino,  E.,  Martino,  L.,  “Object-Oriented  Database  Management  Systems: 
Concepts  and  Issues,”  Computer,  April  1991. 

[6]  Haao,  D.,  “The  Object-Oriented  Database  Management;  A  Tutorial  On  It’s 
Fundamentals,”  Proceedings  of  the  Second  Far-East  Workshop  on  Future 
Database  Systems,  Kyoto,  Japan,  April  1992. 

[7]  Haao,  D.,  “Interoperable  and  Multidatabase  Solutions  for  Heterogeneous 
Databases  and  Transactions,”  a  speech  delivered  at  ACM  CSC  1995,  Nashville, 
Tennessee,  March  1995. 

[8]  National  Air  Intelligence  Center,  Pulsed/CW  Tree  Measurement  Guide  Table,  July 
1992. 

[9]  National  Air  Intelligence  Center,  RPA  Measurement  Guide  Table,  July  1992. 

[10]  Stimson,  G.,  Introduction  to  Airborne  Radar,  Hughes  Aircraft  Con:q)any,  1983. 

[11]  Friedai,  R,  Principles  of  Naval  Weapons  Systems,  United  States  Naval  Institute, 
1985. 

[12]  Badgett,  R,  Design  and  Specification  of  an  Object-Oriented  Data  Definition 
Language,  Master’s  Thesis,  Naval  Postgraduate  School,  Monterey,  California, 
September  1995. 

[13]  McKenna,  T.,  Lee,  J.,  The  Object-Oriented  Database  and  Processing  of 
Electronic  Warfare  Data,  Master’s  Thesis,  Naval  Postgraduate  School,  Monterey, 
California,  to  be  published  March  1996. 


87 


88 


INITIAL  DISTRIBUTION  LIST 


1.  Defuse  Technical  hifonnation  Center  . 2 

8725  John  J.  Kingman  Rd.,  STE  0944 

Ft.  Belvoir,  VA  22060-6218 

2.  Dudley  Knox  Library,  Code  13  . 2 

Naval  Postgraduate  School 

Monterey,  California  93943-5101 

3.  Sharon  Cain  . 1 

NAIC/SCDD 

4115  Hebble  Creek  Rd 
Wrigiht-Patterson  AFB,  Ohio  45433 

4.  Chairman,  Code  CS  . 1 

Con^uter  Science  Department 

Naval  Postgraduate  School 
Monterey,  California  93943 

5.  Dr.  David  K  Hsiao,  Code  CS/HS  . 1 

Conq)uter  Sdence  Department 

Naval  Postgraduate  School 
Monterey,  California  93943 

6.  Dr  C.  Thomas  Wu,  Code  CS/KA  . 1 

Computer  Science  D^artm^t 

Naval  Postgraduate  School 
Monterey,  California  93943 

7.  LT  Kevin  M.  Coyne  . 1 

203  Colmar  Rd 

Seaside,  California  93955 


89 


